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

[liana Ye <liana.ydisg@juno.com>]

On Fri, 7 Dec 2001 11:36:37 +0800 "James Seng/Personal"
<jseng@pobox.org.sg> writes:
> Liana,
> 
> I think you are way out of line here so please drop that line of
> argument, especially one which get personal.
> 
> You may be frustrated at a evil that does not exist. I shall try to
> summaries what John's email to Deng few months back said, hope that
> will help you understand the IETF.
> 
> To get IETF interested in a solution, there are typically two step.
> 1. Conviencing the IETF it is a worthwhile problem to solve
> 2. Presenting the solution to the IETF
> 
> For TC-SC, I think the group is pretty much convienced of the 
> problem
> and something we should at least attempts to solve. We already cross
> that barrier. Any further examples of why TC-SC should be solved etc
> would only frustrate others who is already in part 2 of the problem, 
> ie  finding the solution. 

I did not know we have that consensus until now.


> Any analogy of other scripts to TC-SC is never going to be accurate,
> whether you use Latin + Armeniam, or Japanese, or anything. Human
> language by definition is complex, that makes our job even harder, 
> and
> each language is unique in its own way. In this sense, actually 
> Michel has a point, more than you care to admit.

If I admit it, it would be taken as there is no reasonal 
solution for us too.  

> Going back to our topic of the two step, given that the group is in 
> part
> 2, what we need are proposed solutions. And so far, I dont think the
> group here is convienced of any solution is worthwhile to pursue.
> Sometimes we may have to say, "Sorry it is not possible to be done 
> with
> the existing technology we have now" even though we may agree with 
> part 1.
> Repeating part 1 again and again will not help anything because we
> already convienced of it, just not part 2, the solution.

I am glad that you are telling me, we are in step 2 now. 


> To give you an analogy (one that is harder to dispute of course :-),
> when IDN first started, we always on a basis that the group may 
> declare
> "no solution" as the conclusion. In fact, we may jolly well still do 
> so now, ie, we declare "no solution".
> 
> And to give you another example of the 2 step process, reordering is 
> one 
> which we have a reasonable solution (part 2). Unfortunately, the 
> group
> here is not convience at the problem it solves is worth solving 
> (part 1). In IETF, this is typically known as "solution looking for a
> problem".  Therefore, do we still keep reordering in the pool in 
> hope that there will be a "problem" which will crop up in the future,
or 
> lets drop it? It is a question the group have to ask ourselves.
> 
> -James Seng

Okay, let us move on then. 

Reordering is an effective technique used by itself 
when data organization is not a primary concern of a 
system design.  If the whole UCS flatly goes into AMC 
and scrambled up, reordering adds to it and gaining
a few bytes, the complexity is not a big issue.  No one is
going to care after 5 years when it become stable and 
in place, no one is going to debug it either anyway.  
Most of us are going to enjoy the few bytes we have 
saved here.   If  the idn architecture goes for a flat 
Unicode treatment, I say keep it.

My concern is the UCS code table is already complex 
for us to deal with, and I do respect the Unicode 
techinical directors  who have done a hell of a job to 
organize them into the current form.  This is the 
first step of data-centric programming. 

1) The current codepoints organization provides 
  reasonable clue for us to use language tag 
  to solve our problem, the tags are dependent to
  the positions of the codepoints imply, it shall not
  be altered by reordering;  
2) Phonetic codepoint encoding will enable us to 
  diagnosis codepoint problems in DNS, which is
  dependent on the UCS code organization too. 
If we are using language tag and phonetic encoding
then the majority of IDN names are sortable and 
diagnosable in DNS, which are not subjected for 
 AMC encoding.  This is my assumption,  a readable 
IDN naming in DNS format will be much in demand, 
such that  the code points, left out of phonetic encoding, 
to be fed into AMC will be scattered cross UCS table, 
and the benefit from reordering diminishes.  In either
of the above cases, I say drop it.
 
Liana