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

From: [email-masked]
Date: Mon, 3 Dec 2001 01:46:23 EST

In a message dated 2001-12-02 19:33:03 Pacific Standard Time, 
[email-masked] writes:

> I'm not sure the difference of "marketing solution" and "engineering 
> solution" you mentioned.
> I'm try to assume I know it. So, if a reasonable requirement raise from end 
> users, we should
> find a theorized solution(engineering solution) to meet the requirement. 
> Then we put it into 
> practice(marketing solution) and adjust the improper parts. And, real 
> solution rises. 

Sorry, I keep forgetting that there are marketing people participating in 
this discussion.  When I said:

> It might be a nice marketing solution, but it is not an engineering 
solution.

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.

An engineering approach might be to look at the problem, determine whether it 
must be solved completely or only partially to satisfy the requirements, and 
then determine how completely the problem can in fact be solved.  If it is 
determined that the problem MUST be solved completely, but CANNOT be, then 
the engineer must throw the requirements back over the fence to be modified 
or excised.

A marketing solution might be to defer the question of whether a partial 
solution is adequate, and accept whatever solution can be engineered on the 
basis that SOME users will be satisfied.  After all, satisfied users = $.  
Except that maybe it turns out that the partial solution was not adequate 
after all, and those "satisfied" users (who may not have been fully informed 
of the limitations) end up disgruntled and distrustful of the software.  
Marketing grumbles internally about the incompetence of the developers in not 
satisfying the customers' needs, then proposes a round of "fixes" to try to 
salvage the situation in the next version.

I apologize to all the intelligent, thoughtful, ethical and pragmatic 
marketing people out there for this simplistic and stereotyped picture.  
Certainly, good marketing decisions are made every day.  I do believe, 
however, that any IDN strategy devised by the Internet ENGINEERING Task Force 
must be based on an engineering approach.  That means that when considering a 
CJK-specific enhancement to the already-proposed IDN mechanisms, whether it 
be language tagging or blind SC/TC equivalence or whatever, two questions 
must always be kept in mind:

1.  MUST this problem be solved completely in order to succeed?
2.  CAN this problem be solved completely?

If the answer to #1 is Yes and #2 is No, then DON'T DO IT.  Sometimes, 
marketers, half a solution is worse than none at all.

-Doug Ewell
 Fullerton, California

---

From: "xiang deng" <[email-masked]>
Date: Mon, 3 Dec 2001 14:59:39 +0800

> this discussion.  When I said:

The market is built by end users, so To speak for end users is our responsibility.
From this point, I'm proud to be a marketing people. If our users will  be harmed,
please call me marketing people. I'll loud for the market I love heartly.

Regards
Deng xiang

---

From: "xiang deng" <[email-masked]>
Date: Mon, 3 Dec 2001 15:46:56 +0800

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

> salvage the situation in the next version.

The problem to you is "SOME", BUT to me is "ALL" CDN users. 

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

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?

> marketers, half a solution is worse than none at all.

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.

Because any IDN strategy devised by the Internet ENGINEERING Task Force 
must be based on an engineering approach. So all engineers have responsibility to 
solve real problem of the world, not just satisfy current achievement. 

As a marketer is not a shameful occupation, a engineer have right to look down others.
The beautify world is not just bulit by engineer.

Regards
Deng xiang

---

From: John C Klensin <[email-masked]>
Date: Tue, 04 Dec 2001 11:14:47 -0500

--On Monday, 03 December, 2001 15:46 +0800 xiang deng
<[email-masked]> wrote:

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

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

(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

---

From: "xiang deng" <[email-masked]>
Date: Wed, 5 Dec 2001 09:24:50 +0800

Hello John:

Before we begin the discussion, I suggest that we should add some 
basic information as the basic points of the discussion.
(1) All scripts/characters/codepoints have themselves' developing history.
The history of Han character is same. From a glyph appear firstly to today, 
it had changed many times for history-character-reform. 

So our discussion should include the whole history or not.  My personal 
viewpoint is: To explore history is not significance, the ancient glyphs will
never be used in our realistic life, unless the historian research these glyphs.

(2)  The last reform of Han character is begun by Japan/Korea/Chinese mainland.
The basic point of the reform is Traditional Chinese Character (Finished by 
Wei dynasty and Jin dynasy of China). This kind of TC is widely used by 
Japan/Korea/Taiwan/Chinese mainland in current.

This reform was begun by Japan, and Chinese mainland made a big step.
So there is the publish of "A Complete set of Simplified Chinese Character"
which is contributed by the Committee of National Language and Chinese 
Character of China.

Regards
Deng xiang

---

From: "xiang deng" <[email-masked]>
Date: Wed, 5 Dec 2001 17:32:29 +0800

> I'm unconvinced this is true.  Please convince me.

Mainly, there are four drafts which relate with this subject:
(1) draft-ietf-idn-tsconv-03.txt (HSE->Nameprep->Validation->AMCZ)
(2) draft-ietf-idn-tsconv-02.txt (Nameprep->HSE->AMCZ extension)
(3) draft-mealling-sls-01.txt  (Lay2->IDNA)
(4) draft-ietf-idn-lsb-ace-02.txt (Nameprep->Reordering->AMCZ)
If there is something wrong,  authors correct me please.

> which simplified forms (or traditional forms) exist, are

If you agree the two basic information I had mentioned.
So we have met the whole current Chinese character reform.
 
> least, in some non-DNS mechanism.

Not precision, About 200-300 Han characters are belong to 
1:n ,n:1,1:(n+1),(n+1):1  and so on. 
On Tang dynasty(A.D. 618-907), Chinese Traditional Character
spreads to Korea, Japan and other areas. For being widely used and
long distance and long history,  the meaning and form of Some TCs
begin change. One TC might have several forms, slowly and slowly,
the different forms have different connotation. So these TCs relate with
context.

For technical viewpoint, if we want to do something about it, we need 
artificial intelligence technic. If not, what we can do is very limited.
 
So if adding these information, Could you reconsider what
your conclusions ?