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

From: [email-masked]
Date: Tue, 28 Aug 2001 13:40:36 -0700

Hi, James and Chinese experts:
  You are right on the TC/SC equivalence not in Unicode.  
I know they wanted to put it in long time ago, so I assumed
it is reflected in there some how.   I have just read a reason
that it is not in there, because they think it is too difficult to 
put it in.   I happend to have an idea that 1100 half size  
code point may solve part of the problem and another 200
TC/SC listing completes it.  This can be used in [nameprep].
What do you think?
.
Liana 

On Mon, 20 Aug 2001 13:53:38 +0800 "James Seng/Personal" <[email-masked]>
writes:
> > The SC character set has been used for decades and has went
> > through extensive nationwide testing in China.  SC is stable and 
> they
> are
> > properly reflected in Unicode standard.   The question is a
> definition:
> > is TC/SC a case folding?  It seems that in this WG, there has no
> > consensus on this definition yet.
> 
> I am not sure what you mean by "properly reflected" in Unicode 
> Standard.
> If you mean it is in ISO10646 codepoints, then yes, both TC/SC are 
> in
> the code points. But if you saying Unicode Consortium have proper
> definition of TC/SC, then I afraid to say there is none.
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 29 Aug 2001 10:20:08 +0200

> TC/SC listing completes it.  This can be used in [nameprep].

I would be happy to see a complete proposal.

draft-ietf-idn-tsconv-00 describes a TC/SC mapping for 2064 traditional/
simplified pairs, saying that other tables are needed for single/many
and many/single mappings.

This means that we have a documented proposal on what to do with 4128 
characters.
In Unicoode 3.0, there are 23.658 *more* characters classified as "Han"; 
Unicode 3.1 adds 42.711 more, and it has been noted here that because of 
the way Chinese linguistics work, it is almost 100% certain that there will 
be more added.
I assume (foolishly) that for some large class of these characters, the 
answer is "don't touch them" when mapping TC/SC - but I have no way of 
telling which characters belong in that class.

If you can come up with a proposal that describes what to do about ALL the 
Han characters in Unicode, I will be very happy to hear it.

Until then, I have to say that I have not seen any complete proposal.
Remember - the implementations of the algorithm for the non-Chinese part of 
the world will mainly be done by non-Chinese-speaking programmers; it's got 
to be simple & complete enough that even I can get it right...

             Harald

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Aug 2001 07:31:15 -0400

--On Wednesday, 29 August, 2001 10:20 +0200 Harald Tveit
Alvestrand <[email-masked]> wrote:

> draft-ietf-idn-tsconv-00 describes a TC/SC mapping for 2064
> traditional/ simplified pairs, saying that other tables are
> needed for single/many and many/single mappings.
> 
> This means that we have a documented proposal on what to do
> with 4128 characters. In Unicoode 3.0, there are 23.658 *more*
> characters classified as "Han"; Unicode 3.1 adds 42.711 more,
> and it has been noted here that because of the way Chinese
> linguistics work, it is almost 100% certain that there will be
> more added. I assume (foolishly) that for some large class of
> these characters, the answer is "don't touch them" when
> mapping TC/SC - but I have no way of telling which characters
> belong in that class.
> 
> If you can come up with a proposal that describes what to do
> about ALL the Han characters in Unicode, I will be very happy
> to hear it.
> 
> Until then, I have to say that I have not seen any complete
> proposal. Remember - the implementations of the algorithm for
> the non-Chinese part of the world will mainly be done by
> non-Chinese-speaking programmers; it's got to be simple &
> complete enough that even I can get it right...

And, unless whatever is done is isolated -- through procedures,
structure, or layering-- in a way that is robust, accessible to
all users of URLs based in the Chinese language, and that does
not fragment the Internet, we also need to be sure that the
tables and mechanisms that do SC/TC equivalence don't
accidentally map Kanji or Hangul into SC.

   john

---

From: Martin Duerst <[email-masked]>
Date: Wed, 29 Aug 2001 20:45:05 +0900

>accidentally map Kanji or Hangul into SC.

No problem for Hangul, which is a completely different script.
But for most Hanja (ideographs as used in Korea) and many Kanji
(only many because some are already the same as SC, and in
some cases, Japan has it's own simplifications), there is
absolutely no chance to be successful (i.e. only map SC/TC,
but not Hanja or Kanji). If that's the requirement (and I
agree it is), then we don't have to continue the discussion.
Sorry if I disappoint anybody :-(.

Regards,   Martin.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Aug 2001 07:07:57 -0700

At 01:20 AM 8/29/2001, Harald Tveit Alvestrand wrote:
>>    I happend to have an idea that 1100 half size

Excuse me, but I had the impression that solving this problem was rather 
clearly outside of the requirements for this working group.

At a minimum, it would be very helpful to get explicit resolution about the 
requirement to solve this, in this working group, as well as the 
requirement to solve it immediately, rather than consider it for a later 
version of the working group effort.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: "xiaodong lee" <[email-masked]>
Date: Thu, 30 Aug 2001 09:31:37 +0800

Martin 
I agree. we must consider Hanja and Kanji.
so we must find a feasible solution to avoid that. though the solution maybe not perfect.
do you think it is impossible to find that?

---

From: [email-masked] <[email-masked]>
Date: Thu, 30 Aug 2001 12:09:19 +0800

Hi !  Klensin:
           May  I  ask a question related in draft-klensin-dns-search-01.txt
?
2. A three (or four) search-layer environment.
(1) The DNS, with the existing lookup mechanisms
(2) A restricted, facet-based, search system.
(3) Commercial, localized, and potentially topic-specific, search
   environments.
(4) Something else?

          The current existed and used Letter-Digit-Hyphen DNS server is the
Layer1 mechanism. Now ,what is the layer of   nameprep + IDNA  ?  Actually,
the native coded multilingual domain name  will be treated by AP and passed
to nameprep module and transfomed to ACE name, the ACE name will be feed to
resolver of LDH-DNS , so it is backward compatible to pure ASCII  domain
name.
           The input of resolver module is the interface of Layer2 and
Layer1   ?
> structure, or layering-- in a way that is robust, accessible to
          I think the procedures, stucture, or layering is the module above
layer1 ?
But it must be between name-input of AP and Layer 1 input interface . My
question is
what is the relation betwwen IDNA , Layer 3 , Layaer 2 , nameprep and  Layer
1 ?
Does IDNA and nameprep are in the layer of  Layer 2 ?  How a restrict facet
search system  communicate with Layer1 thru which module ?

> accidentally map Kanji or Hangul into SC.

    Does there are a defined port or module interface to let the isolated
function module can be link to cooperation ?  Thanks !

L.M.Tseng