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

From: [email-masked]
Date: Mon, 3 Dec 2001 16:29:40 EST

In a message dated 2001-12-02 23:55:02 Pacific Standard Time, 
[email-masked] writes:

>> what I meant is this: Users want a solution to a certain problem, such as
>> SC/TC transliteration.  Unfortunately, the sad truth is that not
>> everything
>> users want is necessarily feasible, or even possible.
>
> Correct except SC/TC conversion. There is solution on the desk, so it isn't
> possible, it's existence.

Does the solution work for all CJK code points?  Are there any "holes" in the 
solution that will cause confusion and frustration for users?  (i.e. "Why 
does it work for this character but not for that one?")

If the solution that is "on the desk" really does work for all CJK 
characters, and does not violate the Law of Least Astonishment, and does not 
involve any unreasonable tradeoffs, then it is a greatly improved system 
compared to those that have been discussed here in the past.

> "satisfied users = $", you look down on users. It include youself while you
> are a user.

My concern is that a long-term structural change is being proposed, and it 
should be solid and stable, not geared toward next quarter's bottom line or 
being first into a new market.

You probably should know that as a software developer, I am deeply involved 
in the requirements analysis process and have often been given credit for 
putting the needs of the customer first.  I do care about users, and I have 
seen what happens when users are promised functionality that is not actually 
available, or not ready for prime time, or not completely thought out.  The 
net result, after the initial excitement, is dissatisfaction and distrust.  
Users are indeed important; they are the sole reason the product exists.  So 
it is important to give them a top-quality solution.

> Before we publish the software, we had find the problem, we'll don't fix it
> and try to salvage the situation in the next version. WHY not salvage the
> situation in this version?

Well, that's true, but it's kind of a twisting of what I meant.  What I meant 
was that if we implement an inadequate CJK solution, or one that causes undue 
hardship on the rest of the ACE and nameprep stages, NOW, it will only have 
to be "fixed" with the next version.

> If a old patient will die for serious heart disease, there is no way to cure
> completely.
> If a poor nation fall into serious famine, there is no way to help them all.
> If the answer to #1 is Yes and #2 is No, then the world will be hell of
> human being.

Gee, what's wrong with this analogy?  In these cases, the answer to #1 is NO. 
 That is, it is *not* necessary to solve the problem "completely" (i.e. cure 
the patient "completely" or feed every last citizen) in order to effect a 
significant improvement in the welfare of the patient or nation.

By contrast, CJK users may well expect (demand) SC/TC equivalence to work for 
all Han characters if it works for any, and so the partial solution may be 
worse than none.

-Doug Ewell
 Fullerton, California

---

From: [email-masked] <[email-masked]>
Date: Tue, 4 Dec 2001 09:48:55 +0800

Hi !  Mr.DougEwell2:
        Let me give some explanations to your comments.
----- Original Message -----
From: <[email-masked]>
> being first into a new market.

 What  are solved ?
         The  IDN sublayer can/need  not solve the language translation
problem. Users need a IDN to satisfy:
       (a) can communicate with TC/SC  hostname
       (b) to reduce the 2^N records in registration.
Administrator need a IDN to satisfy:
       (c) to avoid the un-predictable resolving of  hostname in delegated
DNS
    In this mailing list there are many suggestions , but these 3
requirements are come from a fact , CJK characters are not completely
unified, there are a lot of variants with the same meaning and pronouncing.
All the requirements can not be solved by this IDN sublayer. But if there
are no basic mechanism or scheme in the core sublayer , the upper layer work
will not be happened and compatible. The most basic core element is the
validation module that will validate the CJK TC/SC mixed hostname can be
further treated by ACE encoder or not.

L.M.Tseng

---

From: "xiang deng" <[email-masked]>
Date: Tue, 4 Dec 2001 09:38:54 +0800

> does it work for this character but not for that one?")

At first, you should know why the SC/TC conv was intruduced, it's to avoid 
the confusion and frustration for users while they input SC and TC. Reasons:
  Some Han characters have many variants, users can input whatever they like.
While there isn't a mechanism to make these variants to match, users will 
confuse and frustrate the situation.

If we don't concern other opinions, the simpliest solution is just do SC->TC
conversion or TC->SC conversion, So all characters which have variants will
work. But things aren't always be simply, we must concern other important 
factors and make the solution satisfy all Han character users.
 
> compared to those that have been discussed here in the past.

From engineering viewpoint, I prefer the former solution. It solve the issue more
completely.

> being first into a new market.
 
Correct. the long-term structure should involve the rooms to solve the issues 
which we can predict. If not, why not try to think other ways. We all face the 
serious pressure, but if there isn't a good solution, we'll be shame to answer 
the users' questions.

> it is important to give them a top-quality solution.

Thanks you for your education about principles of software developing, though
I had learnt it again and again.
And thanks you for you care about users, if it includes CDN users.
So, agree with a top-quality solution. 

> to be "fixed" with the next version.

If it's a realistic advice, Could you tell me how to "fix" it in the next version?
If the method haven't creativity and is same as the current, 
why not "fix" it in this version?

> significant improvement in the welfare of the patient or nation.

So please don't use a absolute attitude to analysis a real issue.
 
> all Han characters if it works for any, and so the partial solution may be 

Maybe.
If we do nothing, everyone will frustrate while he use CDN.
If we do something, maybe 20% will frustrate.
So we should make a decision whether to do it or not.

Regards
Deng xiang

---

From: John C Klensin <[email-masked]>
Date: Tue, 04 Dec 2001 09:52:15 -0500

--On Tuesday, 04 December, 2001 09:48 +0800
"=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?="
<[email-masked]> wrote:

>...
> requirements are come from a fact , CJK characters are not
> completely unified, there are a lot of variants with the same
> meaning and pronouncing. All the requirements can not be solved
> by this IDN sublayer.

I think most of us understand this.

> But if there are no basic mechanism or
> scheme in the core sublayer , the upper layer work will not be
> happened and compatible. 

This is the statement that I, at least, still don't understand.
Why is it not possible to 

	* register a DNS name, in, e.g., IDNA-ized SC, and then 
	
	* do the TC-SC mappings, and resolution of ambiguous
	cases as needed, in an upper sublayer?

Put differently, if we agree that the whole TC-SC matching
requirement cannot be satisfied at the DNS sublayer, why is doing
_some_ TC-SC mapping necessary at that sublayer?  Doing it all in
one place, at the sublayer at which all of the issues can be
addressed, would seem to me to have some elegance about it and be
much better from a modularity standpoint.

> The most basic core element is the
> validation module that will validate the CJK TC/SC mixed
> hostname can be further treated by ACE encoder or not.

But, again, why do it there at all?   Why not just make rules,
presumably per-registry, about the preferred form for
registrations (so as to avoid large numbers of "equivalent"
registrations) and then solve the mapping/ matching problems at a
different sublayer?

Sorry for my ignorance here, but my sense is that we are just not
communicating very well about this key issue.

    john

---

From: "???" <[email-masked]>
Date: Wed, 5 Dec 2001 10:43:33 +0800

Dear  John:
                        To do right thing is never too later.  I must
thanks  you give me the chance to explain it.
        I have asked a question about the nameprep belong to which layer
on your  multi-layer DNS searching architecture.  I do not get a clear
answer.  Traditional LDH DNS is server based approach,  current IDN use
client side ACE encoding before  
passing the query to resolver,  it is an additional sublayer above
traditional DNS system.  Now, the burden and function of DNS server for
IDN is not so different , even there are  TC/SC IDN comparison as the
same in DNS server. We do not expect DNS can do any thing. 
> -----Original Message-----
> From: John C Klensin [mailto:[email-masked]] 
> This is the statement that I, at least, still don't 
> understand. Why is it not possible to 
> 
          It is possible ! Just like you can use a screen based Han
character translator such as NJStar to do transliteral conversion to
another CJK characters.  You can solved the language communication
problems in this way.  But this approach can not solve the basic
requirements (let me copy them back).
----  What  are solved ?
----       The  IDN sublayer can/need  not solve the language
translation problem. 
----Users need an IDN to satisfy:
----        (a) can communicate with TC/SC  hostname
----        (b) to reduce the 2^N records in registration. 
----Administrator need an IDN to satisfy:
----        (c) to avoid the un-predictable resolving of  hostname in
delegated DNS

         Except you assume all the TC/SC IDN are collected in one DNS
registry and no delegation of  sub-domain name. you can not avoid the
requirements of (b) and (c).

> requirement cannot be satisfied at the DNS sublayer, why is 
> doing _some_ TC-SC mapping necessary at that sublayer?  Doing 
> it all in one place, at the sublayer at which all of the 
> issues can be addressed, would seem to me to have some 
> elegance about it and be much better from a modularity standpoint.
>
         Right !  Why not an integrated module ? That is so beautiful !
I think you will not try to use window word to do any simple input for a
small character string. We have suggested to use an external
modified-LDH-DNS server cooperated with IDNA ACE to help to solve the
"openness" of  Chinese characters and  (a),(b),(c) requirements.  But it
need the supporting of  IDNA and nameprep sublayer to do it.  Someone
have suggest to use CNRP to do server approach , but it is all outside
of IDNA and nameprep supporting .  So the problems of (b) and (c) come
back again.
         Why doing_some_TC-SC mapping at that sublayer ?  
The question is basically come from why CJK using a lot of characters
table  and try to insert to here ?  To solve (c) and to reduce the
troubles of (b) , we can not select doing_all_TC-SC mapping at here. To
do ALL must based on language approach that can not solve (b) and (c),
and from the logical definition , it is impossible to do ALL in an
character set with openness properties.
         If you want to find the original source of  Simplified Chinese
Characters of  PRC ,  then the draft provide it ,  the major SC of PRC
is based on that referenced document. It is "all" the source of  PRC's
SC. It is a very small set, but these character pair  are related to all
CJK area, so it is a global issue and it MUST be cooperated in here to
avoid the problems of requirement (c) and partial of (b) and (a). 
         Some people will ask why doing TC/SC in here ? It is a special
offer !  No ! We are forced to solve the requirements of (b) and (c)  to
save us.  TC/SC is not a CASE problem of uppercase/lowercase of ASCII ,
but we just using the property of comparison as the same with
case-insensitive and the individual chinese character always have
meaning associated to it . It is transliteral not a language
translation.  The mapping burden is client not the DNS server.  We  do
not need to rely
the LDH-DNS server to solve our TC/SC problems.
         Many people will not understand why do TC/SC mapping here and
not so happy  , when I ask back why all non-ASCII coded alphabet will be
mapped to ASCII in nameprep ?  Especially  those FULL-WIDTH alphabet
form in native code, such as JIS, GB...  character set.  I must
point-out  these full width alphabet characters never used in LDH-DNS
server , it is not a backup compatible issue.
         We recognize it is necessary to do it , but we also hope TC/SC
problems of requirement (b) and (c) can be understand. 
> hostname can 
> > be further treated by ACE encoder or not.
> 
> registrations) and then solve the mapping/ matching problems 
> at a different sublayer?
> 
                If all people follow the rule of traffic ,  then the
traffic policeman and related organization is not need !
Reversely, policeman can not forced people to follow the rule , but it
can reduce the troubles. It is a mechanism of  layered architecture.
Especially when CJK area all follow the suggestion to do SC/TC in local
module that is outside of IDNA and work independently, then the problem
of (a) (b) (c) come back if there are hostname can be conversion freely.
               The same question can be applied to all nameprep parts.
               At least, Validation can lead delegation DNS to respect
the rule of registration and let CJK area can do advanced name service
based on a common base.  After someday , when people all follow the same
habits then nameprep part can be all removed.

Best regards

L.M.Tseng