Re: [idn] An ignorant question about TC<-> SC

[John C Klensin <klensin@jck.com>]

--On Tuesday, 30 October, 2001 12:59 +0800 xiang deng
<deng@cnnic.net.cn> wrote:

> Paul:
> 
> I'm sure you know it's a problem of IDN in fact, it's not
> created. To refuse the existence of the problem will not help
> to solve it.

I don't believe anyone is trying to "refuse the existence of the
problem".  Certainly I do not, nor have I seen even a hint that
Paul, or Patrik, or others have done so.
 
> It isn't ASCII vs Chinese characters. IDN provide the platform
> for all scirpts include ASCII and Chinese character and
> others. When  IDN is created, it belongs to the whole world,
> anyone have selfish motive haven't the qualification to say
> I'M IDN MEMBER.
> 
> IDN is important for all of us, we hope the dream of IDN to be
> true. In my opinions, the right way is To dig the problem and
> Solve it. 

I think we are all in complete agreement on that topic as well.
Where there may be a difference of opinion is about the problem
to be solved and the process for solving it.

(1) The Process

There are really two steps in the IETF.  The first step is
explaining to others that there is a problem to be solved and
convincing them.  You and your colleagues have done a very good
job of this, perhaps better than you realize.  Almost everyone
is convinced.  If anyone is not convinced, anyone who still
believes this is not a problem, they have been strangly silent.

The second step requires that a proposal be put before the WG.
A very specific proposal, that can be evaluated against _all_
criteria.  This is important for many reasons, but perhaps the
most important is that the solutions for "IDN" (including
solutions for TC <-> SC) exists in a very constrained solution
space, e.g., 

	* The DNS must work globally: Local-only solutions are
	quite easy, but most fragment the Internet and the IETF
	cannot accept a solution that encourages fragmentation.
	
	* More generally, the DNS must continue to work.  If we
	could start over and redesign the DNS itself to do IDN
	better, we could examine a broader range of solutions.
	Note that two approaches to "starting over..." within
	the DNS context have been put on the table, and that the
	WG has expressed little interest in either.  One is the
	series of suggestions that require EDNS mechanisms and
	the other was the proposal to move toward a new DNS
	Class, on that was multilingual from the beginning.
	Each has disadvantages, but they would permit changing
	the DNS rules.  As far as I can tell, the DNS has not
	chosen to change the DNS rules, and I haven't see you or
	your colleagues arguing for either of these approaches.
	
	* The solution that improves matching for one language
	may not destroy matching for another language.

	* Unicode is a given.  Several of us believe that design
	decisions made in Unicode are making the IDN work harder
	than it might be otherwise ("Han unification" is just
	one of these decisions).  But the IDN WG can't change
	Unicode, there are no other _global_ coded character
	sets around (waiting for another one would take a _very_
	long time), and I fear we need to figure out how to make
	it work.  If you have other proposals, they should be
	taken to either the Unicode Consortium, or to ISO/IEC
	JTC1/SC2, or to some other recognized global standards
	body and brought back to the IETF only when they have
	agreed with you on a solution.  Arguing in the IDN WG
	about what, e.g., UTC, should do or ought to have done
	is useless, whether you make those arguments or I do.

And so on.

Without a specific draft, the rest of us can't help you in
evaluating these things; we just go around in circles.

(2) The Problem.

Again, we are in agreement that there is a TC <-> SC problem.
What is not clear is whether that is a problem that can be
solved in the DNS.  No one is suggesting that, if it can't be
solved in the DNS, it is not a problem.  Instead, several of us
have been working very hard on alternatives that could be used
if the DNS is not adequate.  And, again, our hypothesis that the
DNS is not adequate for this problem is just an hypothesis.
Your proposal could convince us otherwise, but, for that, we
need to see a proposal.

   regards,
     john