Subject: [idn] Future difficulties because of IDNA

From: Dan Oscarsson <[email-masked]>
Date: Tue, 29 Jan 2002 09:31:22 +0100

From the discussions I have had on the namedroppers list I see
that at least two things will be more difficult when we introduce
native UCS in DNS because of IDNA:

1) Additional overhead.
    This is because of IDNA, a UCS client MUST first query the server
   if the server can handle UCS, and then send the real query.
   Without IDNA the client could send the query without knowing
   if the server supports UCS or not.

2) DNSSEC will probably be much more complex to handle due to
   having both ACE encoded and native UCS labels.

I see a risk that IDNA will kill native support for internationalisation
of DNS.

    Dan

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jan 2002 10:11:01 +0100 (CET)

> native UCS in DNS because of IDNA:

Dan,

Your summary of that discussion makes the unstated assumption
that the issue is "when".
I think the issue is "if" it makes sense to have what you call native UCS
in the DNS packets.
So far nobody has managed to convince me that the benefit of that improved
encoding efficiency in the DNS packets outweigh the costs relating to
transition combined with DNSsec; what you list here are some of those issues
with an ACE to native UCS transition.
Staying with ACE encoded strings in DNS packets forver avoids this complexity.

If we can get the application protocols to move towards native UCS support
that would be very good. But that doesn't require the DNS packets to contain
native UCS.

BUT: the WG should now really go off and read the documents in WG last call
carefully to make sure that they are as clear as they can be.

  Erik

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Jan 2002 01:18:03 -0800

>    if the server supports UCS or not.

Dan, your claim has not been true any of the multiple times you have made 
it.  And continuing to repeat it will not make it true.

>    having both ACE encoded and native UCS labels.

This does not alter DNSSec complexity at all.

Try to find some criticisms that are valid.

d/

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

---

From: "Lawrence Lai" <[email-masked]>
Date: Tue, 29 Jan 2002 18:31:10 +0800

---

From: "xiaodong lee" <[email-masked]>
Date: Tue, 29 Jan 2002 20:18:33 +0800

Hello, every member of IDN maillist

Firstly, all that I said here is only my personal opinion, if anything
that I present is wrong, please correct me with my pleasure. I am a
student, so I try to understand such problem and express my opinion in a
student's point of view. I often discuss such IDN with my classmates in
Chinese Academy of Sciences; they also doubt why we are still working on
such problem, which has incomplete and faulty basis, in IETF which is
the highest and authoriative techinical organizaiton in Internet area.
Including WG chairs and many kind and wisdom persons, many people have
made many efforts in IDN, and proposed many solutions for IDN, to be
truth, however, current standards and technologies cannot meet the goal
of such WG. It is a big challenge as everyone knows.

Recently, we often talk about the impact of Unicode ambiguity on CJK; I
will follow such concept, which doesn't mean I don't support Unicode CJK
unification that is a great work achieved by some experts in CJK area. 

Of course, I don't want to oppugn if Unicode is appropriate or not,
because there are no better solutions than choosing Unicode as the
standard of IDN. What I want to do is to pick out the default bought by
selecting Unicode and to explain why we do 1-1 mapping in IDN and leave
other cases in other ways, such as registration or IRNSS. Some people in
this mail list oppugn TC/SC draft is an incomplete solution and cannot
be understand, I wish what I said could help them to understand the
difficulty and essential of TC/SC problems.

Nameprep announced that it would follow the change of Unicode. Because
Unicode only collect the scripts of most languages of the world, so it
cannot handle many problems, such as TC/SC. Of course, it doesn't
collect all scripts simply, it has been doing CJK unification, all
characters in same scripts are reduced to one code point in Unicode,
that is very useful in information exchange in CJK area, but it bring
much trouble for us to do TC/SC equivalent in IDN or CDN. So Unicode is
very successful in many technical areas, but it is an incomplete
solution for IDN, for at lease it cannot meet the requirement of CDN,
which own more than 70% code points in Unicode. That is why Mr. Kenny
Huang proposed to prohibit CJK code points in IDNA, I think.

Unicode has done CJK horizontal unification, and as some persons from
Unicode said, they are considering doing vertical unification in CJKV,
which will handle some problems, including TC/SC equivalent. WILL
NAMEPREP FOLLOW SUCH UNIFICATION IN THE FUTURE? I am wondering how to
deal with many problems caused by current IDN selection in the future,
and how does IETF explain such results for so many CJK users? So as a
co-author of Tsconv draft, I proposed to solve some doubtless problems
in IDN, and leave uncertain problems for the future or other area, which
is not a big problem as someone imaged and worried. Theoretically, if
some problems are very difficult to solve, why don't we solve it step by
step? 

If someone thinks I bring a problem not to be worth discussing, just
cancel it please, because when I saw recent many messages around such
problem, I feel a little pity about the future of IDN. Why don't we
select some feasible solution, more than doing hurried LAST-CALL for all
core documents.

Anyway, I suggest all members to consider such problem carefully and put
IDN into a successful process!

Best Regards!
-- 
______________________________________

      XiaoDong LEE ( X.D. Lee )
______________________________________
 China  Network   Information  Center
 Tel.  (O):      +86-10-62619750-3020       
 Email (O):          [email-masked]         
       (P): [email-masked]  
 Homepage :    http://xiaodong.n3.net
______________________________________