Subject: Re: Thread on - Re: [idn] Prohibit CDN code points

From: Kenneth Whistler <[email-masked]>
Date: Fri, 25 Jan 2002 20:07:18 -0800 (PST)

L.M.Tseng asked:

> Dear All:
> In the draft ,
> http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-06.txt
> define the single Unicode code point as follow:
> 
> Unicode [UNICODE] is a coded character set containing tens of thousands
> of characters. A single Unicode code point is denoted by "U+" followed
> by four to six hexadecimal digits, while a range of Unicode code points
> is denoted by two hexadecimal numbers separated by "..", with no
> prefixes.

Patrick, Paul, or Adam may offer further clarification, but this is
basically a Unicode nomenclatural issue.

The string "U+006A" is a denotation for the Unicode code point (in
the overall range of possible values 0..10FFFF), as well as the
character encoded at that code point, namely LATIN SMALL LETTER J.

The case doesn't matter, although the Unicode Standard most
often uses uppercase. So some people would also use "U+006a" or 
"u+006a" for the same Unicode code point.

> 
> My question are:
> Q1:   U+hhhh  can be represented as u+hhhh  or not ?

Yes. And you can also just leave off
the U+ altogether where it is clear you are referring to
Unicode characters, i.e. "hhhh", so for the LATIN SMALL LETTER J,
just "006A" or "006a".

> Q2:   Here U+HHHH  is not a hostname , does it MUST be forced to lower
> u+hhhh or not  in nameprep ?

I think you are mixing things up. If you put a Unicode character
into a hostname, you don't literally put the string "U+006A" (or
whatever) into the hostname, you put the Unicode encoded representation,
in whatever form of Unicode you are using, into the hostname.

Thus, if my hostname was "jam", in Unicode UTF-8, that would be
just 0x6A 0x61 0x6D, since the Unicode values for ASCII characters
like "j" are the same as ASCII in UTF-8.

If my hostname was the Chinese word for 'banana', just to pick
a random example, that consists of two characters (pinyin: xiang1jiao1).
The Unicode values for those characters are U+9999 U+8549. If you
have a Unicode string, that would just be two 16-bit numbers,
0x9999 followed by 0x8549, if using Unicode UTF-16, or the
following byte sequence if using Unicode UTF-8: 0xE9 0xA6 0x99 
0xE8 0x95 0x89.

> Q3:  Puny code  draft  accept  U+hhhh  or  u+hhhh  to let the final encoded
> ASCII character (last character of corresponding  encoded code point)  with
> case upper or lower.

If I am interpreting things correctly, Punycode is defined on the 
Unicode code points, and certainly not on
the short identifier strings for the Unicode code points.
So for the Chinese 'banana' example, you'd be encoding two
code point integers (39321 = 0x9999, followed by 34121 = 0x8549),
*not* the string of integers corresponding to the ASCII
string "U+9999U+8549".

Of course, somebody might want to try having a hostname or
domain name of "U+9999U+8549", but that is a 12 character ASCII
string, and is not the same thing at all as the two-character
Unicode string for the Chinese word for 'banana'.

--Ken

> 
> I   hope draft authors can help to clarify these interconnection point .
> 
> L.M.Tseng

---

From: [email-masked] <[email-masked]>
Date: Sat, 26 Jan 2002 20:59:21 +0800

Dear Kenneth  & all:
         Thanks your response to these questions.
----- Original Message -----
From: "Kenneth Whistler" <[email-masked]>

> character encoded at that code point, namely LATIN SMALL LETTER J.
              You point out another question  I want to know,  the data type
and range of UNICODE point that toASCII function module will be inputed.
Because IDNA may be a common module for all applications,  but  today there
are not only one vender like NSI/ISC as before , so it should define and
describe more clearly.  As the traditional habit in protocol of IETF RFC ,
the parameter are passed by ASCII string,  but if it is ASCII string , the
delimiter of each character and indicater MUST be very clear. Especially ,
there will be some pure ASCII string name may also passed to it.

> following byte sequence if using Unicode UTF-8: 0xE9 0xA6 0x99
       Sorry,  in a function module , like such inportant one " toASCII" ,
the input parameter of  type , size range and representing format should be
defined more clearily to support inter-operability.
> *not* the string of integers corresponding to the ASCII
          You just point out the problem ,  how to differentiate them ?
IDNA  module is a common module shared by most applications or a full set
belong to each AP  independetly is not the same results in these
descriptions .  Does some one can clarify it more clearly ?

> Unicode string for the Chinese word for 'banana'.
          It is different , but you can not avoid people to register such
name .  If it is a common module to all , it should consider the influence
from such input.

Thanks to all the reply
L.M.Tseng

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 26 Jan 2002 14:28:25 +0100

> descriptions .  Does some one can clarify it more clearly ?

IDNA specifies what goes on the wire between two applications. Not what
libraries, functions etc are to be developed to reach that goal.

The functions specified in the IDNA draft is a functional specification on
what must happen with the strings. Not a specification of functions which
should exist in libc or such.

My personal guess is that we will see ToUnicode and ToAscii functions in
libraries which already take care of charset conversion. Like the Text
Encoding Converter from Apple. (see
http://developer.apple.com/techpubs/macos8/TextIntlSvcs/TextEncodingConvers
ionManager/TEC1.5/TEC.38.html)

Similar modules will certainly be developed as perl libraries and what not.

Many of them probably takes a native charset as input (such as BIG-5 or
ISO-8859-1) and not some encoding of Unicode.

IETF extremely rarely develops API's.

  paf

---

From: [email-masked] <[email-masked]>
Date: Mon, 28 Jan 2002 09:32:47 +0800

Dear Patrik Fältström & all:
                   I think to change a subject may be more good .
1. The problems:
          There are many need about character mapping and prohibition of
code points that are  more than the draft of nameprep described,  someone
call them local issue ,  language or area related issue.
2. The  interface before and after IDNA module:
         To solve these problems, the pre-IDNA approach is not clear,
especially in the interface.
Currently,  we can find web navigation of  Realname/Microsoft help to  do
resolving of   Verisign's IDN testbed. But  that is  one possible approach ,
some character mapping and prohibition can be processed in external matching
and conversion server.
         IDNA  approach is based on  ACE  encoding for backward
compatibility ,  we can view the ACE encoding approach is a tunnel
technology between client and server based on current  LDH-DNS server and
TLD.  As discussed in the mailing list , based on exhausted  label mapping ,
some kind of character mapping can be achieved by  multiple RR of
CNAME/DNAME  ,  such small and simple case can be done in this way . If  the
character mapping is a combination  in label then a  gateway to do multiple
matching rule  is need to reduce a lot of  label  records.  Actually a
gateway combined with the function of  UTF-8 DNS-like server may be one of
the approach .
3.  To  force  some character mapping/prohibition  out of  nameprep and call
them local issue without using the option concept  is not a good solution ,
but if  it can not be avoid in this architecture ,  then  the interface of
pre-IDNA  and post-ACE-encoding  MUST be defined clearly .  To use
ACE-string and  TLD as gateway selection  is in the  range of  DNS protocol
. By using  HTTP protocol  and web navigation  or another protocol  to reach
external server to do multiple matching  is out of  DNS  protocol  and out
of the expectation of  DNS manager.

L.M.Tseng

4. Which  solution is beter ?  that depends on requirements of user  and
expectations  of  DNS manager.   All the problem is  "where to do local
character/string mapping ? "   Annotational multi-case Punycode
encoding/decoding is a powerful  tool to do such mapping and multiple
matching  based on a uniform LDH-DNS matching rule.

----- Original Message -----
From: "Patrik Fältström" <[email-masked]>

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 28 Jan 2002 08:03:55 +0100

--On 2002-01-28 09.32 +0800
"=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?="

> call them local issue ,  language or area related issue.

They are language, culture and other context dependent, and therefore a
localization issue, not internationalization issue and out of scope for
this wg.

> especially in the interface.

You mix up a large number of things here. None of them is part of what this
working group is working with.

> resolving of   Verisign's IDN testbed.

This binding doesn't exist explicitly. Some web browsers after a NXDOMAIN
response is going to a search system like Realname/Microsoft with the
domainname. That is one thing. Lack of support for the IETF IDN wg results
in the browsers of today is another. None of these have to do with
localization or "interface to IDNA".

> But  that is  one possible
> approach , some character mapping and prohibition can be processed in
> external matching and conversion server.

Yes, but that is done in a layer "above" DNS. Not as a replacement or in
parallell with DNS. Domain name is one thing and keyword another. You mix
them up.

> TLD.

Sort of, but rather from the client application and the registrant as the
encoding is invisible for the server aswell.

>  As discussed in the mailing list , based on exhausted  label
> mapping , some kind of character mapping can be achieved by  multiple RR
> of CNAME/DNAME  ,

Not DNAME. DNAME should not be used. And, you do not do character mapping. 

In DNS you make sure that a client get a response regardless of what the
query is. You might say that the result is the same for the user, but, it
is not translation which is done.

>  such small and simple case can be done in this way .

Yes.

> If  the character mapping is a combination  in label then a  gateway to
> do multiple matching rule  is need to reduce a lot of  label  records.

No. As I explaind on a different thread last week (see the archives), as
soon as you change the matching rules locally, you change the definition of
a RR-Set.

> Actually a gateway combined with the function of  UTF-8 DNS-like server
> may be one of the approach .

No. UTF-8 have nothing to do with this. UTF-8 is just another encoding of
Unicode.

What you really talk about (I think) is how to handle the IDN solution as
soon as possible, before applications have support for IDNA. And, your
proposal is to store whatever garbage the applications will send over the
network in the DNS servers in the encoding the clients happens to use. This
implies BIG5, UTF-8 encoded non-nameprepped Unicode, ISO-8859-1 and many
other charsets.

That should _NOT_ be done, as there is no way of discovering what charset
is used, and this will because of this lead to explicit domain name
infridgement which in turn is treated as trademark infringement.

Further, the application layer protocols can not handle other characters
than LDH, so you loose anyway.

All of this has already been discussed many times on this mailing list.

Especially the definition of RR-Sets. Didn't you see that last week?

> 3.  To  force  some character mapping/prohibition  out of  nameprep and
> call them local issue without using the option concept  is not a good
> solution , but if  it can not be avoid in this architecture ,  then  the
> interface of pre-IDNA  and post-ACE-encoding  MUST be defined clearly .

Maybe, but it is not a work for IETF. IETF do not work with API's.

IETF have not made API's for access to quoted-printable.

> To use ACE-string and  TLD as gateway selection  is in the  range of  DNS
> protocol . By using  HTTP protocol  and web navigation  or another
> protocol  to reach external server to do multiple matching  is out of
> DNS  protocol  and out of the expectation of  DNS manager.

Exactly.

> matching  based on a uniform LDH-DNS matching rule.

As I have said earlier, it is discussed in another forum than this wg.
Please stop talking about it here.

   paf

---

From: [email-masked] <[email-masked]>
Date: Mon, 28 Jan 2002 17:48:08 +0800

----- Original Message -----

> parallell with DNS. Domain name is one thing and keyword another. You mix
                The possibility of external  NON-LDH-name server is existed
. It is isolated from current LDH-DNS server or cooperated by layer upon
LDH-DNS server or to  replace it or in parallel can not be easily
predicated.

> Especially the definition of RR-Sets. Didn't you see that last week?
            I think you talk a solution that TWNIC/CNNIC have been used  in
transition state,  to a registry , the original name that is registered is
independent of  any encoding ,  that will be there.  Try to support service
in testbed can find many important issue.  I  have implement an experimental
Virtual Domain Name system that based on RACE , but support  any query  of
UTF-8, BIG5 , RACE  because they can be identified without language tag ,
but  mixed BIG5 , GB is not so easy to differentiate them as you point-out,
if it is suported by  HTTP protocol with lang-tag and used for browser ,
there are no problems,  that is the system you called  keyword  approach and
now I think  Realname/MicroSoft/VeriSign used in resolving by web
navigation. Unfortunately , that is only my personal experimental system to
try to solve TC/SC problems.
           Why I mention UTF-8 here , because based on current BIND DNS
technology that can  do character mapping easily .  If these server are
isolated from current LDH-DNS server , it can be a layer-2 server , it also
can be a gateway to do character mapping .
           Whether it is a Layer-2 server betwwen AP and IDNA nameprep or
it is a gateway between resolver and LDH-DNS server that is not so
important. Even I know the solution existed  in  multi-case AMC-Z encoding ,
but nameprep and IDNA fixed to refused to support it .  I  still  want to
solve our TC/SC problems first or we should to avoid to use the
non-suporting scheme.

> Please stop talking about it here.
            To do  matching  by nameprep and ACE conversion then by LDH
server with single matching rule or to do multiple matching in higher layer
or gateway  then do single matching in LDH DNS server is not so boundary
clearily .  To us , we can select any approach to solve the  problems that
are initiated from UNICODE and this  IDN WG.
            May be the current nameprep should be  a local issue.

L.M.Tseng

---

From: [email-masked] <[email-masked]>
Date: Tue, 29 Jan 2002 00:35:07 +0800

Dear Patrik Fältström :
                  Sorry , the previous mail has a lot of spelling error.
> soon as possible, before applications have support for IDNA. And, your

            I  think there are some mistake in here.  About  JAN  2000 ,
one company come to Taiwan and announced they supply  ML-gTLD  "公司"
(chinese name of .com) registration and  it will be a IETF and ICANN
standard in near furture .  The worst , this company also announced they
also supply ML-ccTLD "台灣" (chinese name of  TW) .  We find this company
used the client solution to transform ML to ASCII string and append a domain
to it.  That is one of the technology will cause infringement.
           The customer of  TWNIC is very worry about their  chinese domain
name will be lose . Since  the registrant registered their name  with both
chinese full company name and  LDH domain name in paper form, so I suggest
TWNIC should  put the chinese company name as the domain name by  this form
ML.ML-com.tw  to show to  them that  their name is under best protection of
our NIC.  We will wait the true standard to be approved  then support them
too.  Our NIC does not prefer any approach to work as an IDN solution.
           After that experimental testbed , we find TC/SC problems, so we
keep all attention to this troubles come from UNICODE.  So, we have the
draft about UNAME that basically describe the ACE identifier is necessary,
especially in TC/SC  browser to cross visting another SC/TC web server.

> implies BIG5, UTF-8 encoded non-nameprepped Unicode, ISO-8859-1 and many
           The experimental testbed is restrict to chinese character only
and testing before the nameprep propasal. Actually, the testing registration
do not allow  any  full width ASCII ,  so the problems of  nameprep is
mapped out in registration phase .  We keep only chinese character name and
still wait a world-wide  IDN solution to update.

> infridgement which in turn is treated as trademark infringement.
           My  personal  Virtual DNS server is based on the registered
record to do code conversion and present the  equivalence  name to client,
it is a combined module of BIND DNS and  transliteral code-converter to do
it. If the zone record is legal in a DNS , the transliteral conversion of
name label is the same as the (nameprep + Punycode) doing in client .  The
DNS tree has strong  authorized tree relation check , so it is better than
the client  solution to avoid  infringement by domain name appending .  As I
know , there are still a lot of client side ACE solution to replace  a
ML-COM(chinese name  of .com) and append a ascii-domain name to re-direct it
.  I  just trust  the BIND DNS  software maintener has more experience in
SERVER than client to avoid infringement.  May be it is not true .  But I
must be say IDNA have good potential, because it has one powerful tool-
mult-case Punycode.

L.M.Tseng

---

From: [email-masked] <[email-masked]>
Date: Tue, 29 Jan 2002 10:27:24 +0800

Dear  Soobok:
          I  agree your point .  We may forget current Punycode only
supports single case per character. Even there are a higher service layer
above DNS, the multiple matching result will not apply  the good properties
of multiple-case ACE encoder to connect to 7 bits LDH  DNS server .
          Although there are a lot of equivalent character problems in
UNICODE  can not be solved  quickly,  but the fixed monolithtic IDN approach
should include the flexibility of multi-cased Punycode to support the
furture connection for higher layer service.

L.N.Tseng
----- Original Message -----
From: Postel Services, Inc
....
>In order to do multi-case Punycode correctly and suffiencienly  for TC/SC
and >latin/cherokee/gree/cyrillic and hangul jamo matters and turkish i and
others,  we >should devise *new layer* that would replace current stringprep
one. stringprep is far >from what users want.
...
>In summary,  multi-case Punycode require  completely new reworks of IDNA
draft sets. >it will be like making new ones. I believe it will take another
2~3 years..
...
>Personally, i believe that  DNS should  remain as 7bit ASCII one which is
>internationally recognizable and distiguinshable and verifiable. Instead,
the users' need >for "internationalized *access* to domain names" should  be
solved  *above DNS*   by >the best ways that can serve local user
communities. It will bring  users   more benefits >and conveniences than
fixed-forever monolithic  IDN approach.