Subject: [idn] draft about <draft-ietf-idn-uname-01.txt>

From: Erin Chen <[email-masked]>
Date: Fri, 13 Jul 2001 20:22:27 +0800

Dear IETF & IDN WG:

Attached is <draft-ietf-idn-uname-01.txt>.

This document add a practical case to indicate that using CNAME to
implement
UNAME is workable for Internet application to fetch a unique name. And
show
it could be treated as a further process of NAMEPREP and it is
compatible with
the IDNA aproach.

Thanks for any suggestion and comment!

Erin Chen
TWNIC
 
Internet Draft                                         Authors: Li Ming TSENG
<draft-ietf-idn-uname-01.txt>                    		  Jan Ming HO
13 Jul 2001                                                      Hua Lin QIAN
Expires 13 Jan 2002					          Kenny HUANG                                                               Editor: James SENG

       Internationalized Domain Names and Unique Identifiers/Names

Status of this Memo

    This document is an Internet-Draft and is in full conformance 
    with all provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet 
    Engineering Task Force (IETF), its areas, and its working 
    groups. Note that other groups may also distribute working 
    documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of
    six months and may be updated, replaced, or obsoleted by other
    documents at any time. It is inappropriate to use Internet-
    Drafts as reference material or to cite them other than as
    "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html

Terminology

The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119].

Abstract

One of the biggest technical challenge of Internationalized Domain 
Names (IDN) is how to determine if the two given domain names matches. 
The current approach to this problem is via a process known as 
[NAMEPREP]. 

This document attempts to describe an alternative view and solution to 
the IDN matching problem. It could be treated as a further process of 
NAMEPREP and it is compatible with the IDNA aproach.

There is a practical case to indicate that using CNAME to implement 
UNAME is workable for Internet application to fetch a unique name.

1. Introduction

The Chinese Domain Name Consortium (CDNC) has taken a very keen 
interest in the IDN, in particular, the uses of chinese script in the 
domain names. CDNC are formed by the regional registries (CNNIC, TWNIC, 
HKNIC and MONIC) and have experimented doing Chinese Domain Names 
System for many months.

The primarily motivation for this proposal is due to the lack of 
support of Traditional and Simplified Chinese in NAMEPREP. See [HAN] 
for a discussion of Traditional/Simplified Han Ideograph problems. 

In addition, given the operational experience of the registries, this 
proposal will reduce the operational and deployment cost from a TLD 
managers' perspective based on the examinations and developments in 
CDNC.

Backward compatibility, interoperability, scalability, security, 
operational and deployment are all elements that must be considered as 
part of criteria when designing internationalized domain name system.

2. Background on Legacy Encoding

The most popular Chinese character set used in Taiwan is the 
industrial standard "BIG5" and the corresponding one in China is 
"GBK". BIG5 have primarily Traditional Chinese characters and GBK have 
Simplified Chinese.
In addition, the China government has also mandated that all Chinese 
software in China must support a new standard that supercede GBK known 
as GB18030.

Both BIG5 and GBK are widely used in China, Taiwan, Hong Kong and 
Macao and supported within many operating systems including Windows. 
Thus, supporting these encodings in IDN is essential from a 
geographical perspective.

3. An overview of current proposals and its problems

3.1. ASCII Compatible Encoding (ACE)

The need of supporting ACE in IDN has been extensively discussed in 
the IDN Working Group. Backward compatibility is the strongest 
advantage of ACE. The deployment of ACE neither affects the existing 
naming infrastructure, nor creates potential damage of current 
Internet applications. To move the current Internet to multilingual 
infrastructure, ACE obviously is the most appropriate bridging 
solution.

Although ACE has the advantages mentioned above, but most of the 
user's systems support local encoding. User doesn't want to download 
any special software or upgrade their software in order to handle 
multilingual domain name system. The support of native encoding 
without altering user's software has became an important issue for 
TLD managers'.

3.2. NAMEPREP

The design goal of [NAMEPREP] is to allow users to enter host names 
in applications and have the highest chance of getting the name 
correct. The NAMEPREP process comprises of three basic steps, namely 
"MAP", "NORMALIZATION" and "PROHIB".

The MAP and NORMALIZATION step aims to reduce the number of possible 
representations domain name that should be equivalent. These are 
based upon Unicode Technical Reports [UTR15] and [UTR21]. However, 
when there are multiple representations of the same domain name but 
matching changes depending on languages and context, NAMEPREP will 
fail in these cases. Of our interest, Traditional and Simplified 
Chinese ideograph cannot be handled by NAMEPREP.

4. Alternative view to the problem space

While the IDN WG has been working very hard to solve the ACE and 
NAMEPREP in IDN, it is apparently that there is another view to these 
problems that may give us a different approach and solution.

First, there is an assumption that NAMEPREP IDN is ISO10646/Unicode 
string. In reality, most IDN is often encoded in legacy encoding and 
a additional step have to be taken to covert it to ISO10646/Unicode.

Other than the backward compatibility feature of ACE, ACE is also an 
identifier string for an IDN. And the NAMEPREP process is to unify the 
various possible representations of IDNs to a single "unique name" for 
matching purposes.

In other words, we have a conceptual model.

  +-------+     +---------+   (ISO10646)
  |XYZ.COM|-->--|Transcode|-->------------+
  +-------+     +---------+      +----------------+     +---------------+
       :  (Legacy)         ...---|NAMEPREP/Unified|-->--|ACE/unique name|
  +-------+     +---------+      +----------------+     +---------------+
  |xyz.com|-->--|Transcode|-->------------+
  --------+     +---------+   (ISO10646)

5. Proposal

Given the context of the alternative view to IDN, we can derive another 
set of solution using a directory concept.

  +-------+       +---------+
  |XYZ.COM|-->----|         |     
  +-------+       |         |     +---------------+
       :  (Legacy)|Directory|-->--|ACE/unique name|
  +-------+       |         |     +---------------+
  |xyz.com|-->----|         |
  +-------+       +---------+

In section 3.2., it mentioned there are some ideograph cannot only be 
handled by NAMEPREP's "MAP", "NORMALIZATION" and "PROHIB" essential 
process. To build up a directory system is to doing as a further  
NAMEPREP process. The further process will solve the matching problem.
For example the one to many and many to one mapping.

The purpose of this directory system is to list all the possible 
representations of IDNs and unify them to a unique name. This unique 
name could be an ACE of the most common representation or NAMEPREPPED 
ACE.

The content of the directory is build up upon registration whereby 
registrant will have to provide a list of equivalence representation 
of the domain names they registered.

However, there is still a question of what directory should we use. 
In this document, we shall examine a couple of different solutions.

5.1. LDAP as Directory

Lightweight Directory Access Protocol [LDAP] is one of the most 
widely used directory protocols. In LDAP, there is a concept of 
hierarchy similar to the DNS hierarchy. Hence, it is possible to 
distribute the content of the directory across various LDAP servers 
for scalability and authority control. For example, each registries 
who wish to deploy IDN may setup an LDAP server and to register this 
LDAP with a "root" LDAP server.

The IDN query process would then look something like this:
   a. User Input IDN name into an application
   b. Application does a LDAP query to look for unique name
   c. Application use unique name to do DNS lookup

Advantages:
   - encapsulate the problem in the representation layer and 
     registration time
   - able to handle with unification problems 

Disadvantage 
   - requires all applications to upgrade 
   - additional LDAP lookup overhead
   - policy issues with "root" LDAP server
   - requires access to LDAP servers to function, i.e. can't work 
offline

5.2. CNRP as Directory

Common Name Resolution Protocol [CNRP] is a newly developed protocol 
in IETF that does common names resolutions. In CNRP, there is no 
concept of hierarchy but there is a referrer scheme. Hence, it is 
possible to build a distributed directory system whereby they refer 
to each another.

The IDN query process would then look something like this:
  a. User Input IDN name into an application
  b. Application does a CNRP query to look for unique name
  c. Application use unique name to do DNS lookup

Advantages:
   - encapsulate the problem in the representation layer and 
     registration time
   - able to handle with unification problems
   - no policy issues with "root" CNRP server

Disadvantage 
   - requires all applications to upgrade
   - additional CNRP lookup overhead and no assurance that unique name 
     can be located
   - requires access to CNRP servers to function, i.e. can't work 
offline

5.3. DNS as Directory

Domain Name System [DNS] is a widely established lookup distributed 
directory. There is an existing hierarchy structure and resource 
records are distributed. In theory, the DNS is able to handle 8-bit 
binary string.

The IDN query process would then look something like this:
   a. User Input IDN name into an application
   b. Application does a DNS query to look for unique name which will 
return the       Resource Record of the unique name together

Advantages:
   - encapsulate the problem in the representation layer and 
     registration time
   - able to handle with unification problems
   - existing "root" DNS server with existing hierarchy
   - does not requires all applications to upgrade

Disadvantage 
   - unknown behavior on applications which cannot handle 8-bit 
   - unknown behavior of servers/caching software which cannot handle 
8-bit

6. Solution

Given CDNC operational experience that it is difficult to get 
applications developers to upgrade, difficult to get users to 
download new applications and difficult etc, using DNS as a Directory 
would be the fastest approach to deploy IDN for our users.

6.1. Zone file

Because there are multiple encoding and multiple representation of the 
same name even within the same encoding, for a single name, there are 
multiple binary strings for a single domain name (e.g. ML1, ML2, ML3, 
ML4).

Hence, we would create the following Resource Records within the name 
server. In the Resource Records, it would look like this:

ML1		UNAME		ACE1
ML2		UNAME		ACE1
ML3		UNAME		ACE1
ML4		UNAME		ACE1

ACE1		IN 	A	1.2.3.4.
		IN	A	1.2.3.4.

A "UNAME" Resource Record is shown here. In practice, it could be 
CNAME (except CNAME is unable to handle MX).

6.2. The practical case of implementing UNAME with CNAME

Before the UNAME protocol is defined, in TWNIC IDN testbed, it has 
implimented IDN unique name with CNAME in current stage. When register 
a Traditional Chinese domain name(TCDN) can get another one 
corresponding Simplified Chinese domain name(SCDN). The Traditional 
and Simplified Chinese Conversion is defined in [TSCONV].

The Resource Records is look like this:

TCDN1		CNAME		EDN1
SCDN1		CNAME		EDN1
EDN1		IN	A	IP-of-EDN1

If the EDN1 is not in the same domain with TCDN1 and SCDN1, that the
Resource Record of EDN1 would in the different zone file. The left 
side of CNAME Resource Record would be all of the equivalent ML1, 
ML2 .... Like TCDN1 and SCDN1 are equivalent. The right side of CNAME 
Resource Record would be an unique name of ACE compatible. EDN1
(English Domain Name 1) is a kind of ACE compatible nique name. EDN1 
could be substiude with any kind of ACE compatible unique name. Such 
like xACE encode or random number. Once the xACE is decided by IETF 
IDN WG, the implimentation would adopt the standard. The unique name 
also retains compatible with [IDNA] approach. 

In order to get the unique name EDN1 not the destination IP-of-EDN1,
there would be construct some intermediate server. In TWNIC testbed,
there are Web DNS or DNS proxy as the intermediate server. Any 
application can pass a TCDN1 or SCDN1 to the intermediate server. The 
intermediate server would ask the DNS for the coresponding right side 
which is the unique name. And then pass the unique name EDN1 to the 
application. And then go with the current DNS infrastructure. Once the 
UNAME protocol is defined, there is no more need a intermediate server.

The process could be represented as following:

                                +------+
                                | User |
                                +------+
                                 |    ^
                   Request to AP |    | Response from AP
                   with MDN      |    |                   End system
    +----------------------------|----|----------------------------+
    |                            v                                 |
    |  +--------------------------------------------------------+  |
    |  |                  Application Client                    |  |
    |  +--------------------------------------------------------+  |
    |      |  ^ Nameprepped               |  ^         |  ^        |
    |  MDN |  | ACE compatible            |  |         |  |        |
    |      |  | unique name               |  | IP of   |  |        |
    |      v  |            Nameprepped    |  | unique  |  |        | 
    |  +--------------+    ACE compatible |  | name    |  |        |
    |  | intermediate |    unique name    v  |         |  |        |
    |  |  server      |             +----------+       |  |        |
    |  +--------------+             | Resolver |       |  |        |
    |      |  ^ Nameprepped         +----------+       |  |        |
    |  MDN |  | ACE compatible        |  ^             |  |        |          
    |      |  | unique name           |  |             |  |        |
    |  +--------------+               |  |     Request |  |Response|
    |  | Directory of |               |  |     for     |  |from    |
    |  | DNS          |               |  |     service |  |server  |
    |  +--------------+               |  |             |  |        |
    |                                 |  |             |  |        |
    +---------------------------------|--|-------------|--|--------+
                       Nameprepped ACE|  | IP of       |  |
                       compatible     |  | unique      |  |
                       unique name    v  | name        v  |
                            +-------------+  +---------------------+
                            | DNS servers |  | Application servers |
                            +-------------+  +---------------------+

6.3. Advantages

The strongest advantage to this solution is that:
a. This does not requires our users to download any special software 
or upgrade their software since it is able to handle the native 
encoding of the user directly

b. It will work immediately for ccTLD who wish to offers ML.ccTLD 
services without any changes at the user client

c. It also retains the compatible with IDNA approach so long we keep 
the unique name equivalent to NAMEPREPPED ACE.

d. Existing DNS hierarchy 

6.4. Potential Loopholes

There are many loopholes within this solution that we need to take 
note:

a. Some "smart" localized browser will send out "wrong" binary 
string due to different. For example, English Internet Explorer will 
not be able to handle Chinese double-byte legacy encoding properly.
But if there is the requirement of use double-byte encoding, the 
appropriate application environment is necessary.

b. While Chinese have a handful (usually 2 to 3) representation 
forms for a single IDN, other languages may have much more 
complicated representations which may not be suitable to use this 
approach. For example, if case-folding for Latin character is done 
using this solution, for a string length of 32 characters, it will 
requires 2^32 entries in the DNS. But this could be solved in some 
other means.

c. It might be possible to construct a binary string in some legacy 
encoding which gives the same binary representation for another 
domain name (a.k.a. binary collision). The binary collesion of in the 
same zone could be avoided by registration system and policy. If the 
left side of UNAME (like ML1,ML2, ML3, ML4 or TCDN1, SCDN1) are not in 
the same zone, they would not occur binary collesion. The intermediate 
server would have the ability to decide which zone of DNS directory it 
sould access.

Acknowledgement

Author(s)

Li Ming Tseng, Prof
National Central University, TWNIC
Email: [email-masked]
Tel: +886-3-490-4421

Jan Ming Ho, Prof
Academia Sinica, TWNIC
Email: [email-masked]
Tel: +886-2-2788-3799 x 1803

Hua lin Qian, Prof
Chinese Academy of Science, CNNIC
Email: [email-masked]
Tel: +86-10-6256-9960

Kenny Huang
Asia Infra International Ltd, TWNIC
Email: [email-masked]
Tel: +886-2-2658-6510

Editor: James SENG
i-DNS.net International
8 Temasek Boulevard
Suntec Tower Three #24-02
Singapore 038988
Email: [email-masked]
Tel: +65-2486-188

Editor: Erin Chen
Taiwan Network Information Center (TWNIC)
4F-2, No. 9, Sec. 2, Roosevelt Rd., Taipei, 100 Taiwan.
Email: [email-masked]
Tel: +886-2-23411313#502

Reference

[IDNREQ]	Requirements of Internationalized Domain Names, Zita Wenzel, 
                James Seng, draft-ietf-idn-requirements

[NAMEPREP]	Preparation of Internationalized Host Names, P. Hoffman, 
                M. Blanchet, draft-ietf-idn-nameprep

[HAN]		Han Ideograph (CJK) for Internationalized Domain Names, 
                J. Seng, Y. Yoneya, K. Huang, K. Kim, draft-ietf-idn-cjk

[LDAP]	        Lightweight Directory Access Protocol (v3), M. Wahl, 
                T. Howes, S. Kille, rfc2251.txt

[CNRP]	        Common Name Resolution Protocol, N. Popp, M. Mealing, 
                M. Moseley, draft-ietf-cnrp

[DNS]		Domain Names - Implementation and Specification, 
                P. Mockapetris, RFC1035

[CJKV]          CJKV Information Processing ISBN 1-56592-224-7

[UTR15] 	Unicode Normalization Forms, Mark Davis and Martin Duerst,
                Unicode Technical Report 15.

[UTR21]         Case Mappings, Mark Davis, Unicode Technical Report 21.

[TSCONV]	Traditonal and Simplified Chinese Conversion, XiaoDong LEE,
		HSU NAI-WEN, Erin Chen, GuoNian SUN, CNNIC, TWNIC, CDNC,
		draft-ietf-idn-tsconv

[IDNA]		Internationalizing Host Names In Applications (IDNA),
		Patrik Faltstrom, Paul Hoffman, draft-ietf-idn-idna                                    Cisco

---

From: Erin Chen <[email-masked]>
Date: Fri, 13 Jul 2001 20:28:16 +0800

Dear IETF & IDN WG:

Attached is the draft of :
Evaluation of various ACEs with existing Chinese (BIG5) Domain Names

This document offer an overview of the results of various ACEs that
being
applied to Chinese (BIG5) Domain Names. And give a brief summary of
the evaluation result.

Erin Chen
TWNIC
 
Internet Draft                                                 Abel Yang
draft-ietf-idn-ace-eval-tw-00.txt                              Erin Chen 
Jul 13, 2001                                                       TWNIC
Expires Jan 13, 2002                                           

   Evaluation of various ACEs with existing Chinese (BIG5) Domain Names

Status of this memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as 
    Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

Abstract

    In order to help the ACE (ASCII Compatible Encoding) Design Team in 
    IDN Working Group to selecting an appropriate ACE proposal. This 
    document offer an overview of the results of various ACEs that being
    applied to Chinese (BIG5) Domain Names. And give a brief summary of 
    the evaluation result.

1. Test data and tools

    The sample data were come from TWNIC registration database. All of 
    them are in BIG5 encoding. The amount of the data is 28454. And the 
    data distribution by the length is:

      Length of data     quantity of BIG5 Domain Names
    	2 chars			3762 
	3 chars			3914 
	4 chars			4613 
	5 chars			1723 
	6 chars			1851 
	7 chars			4282 
	8 chars			1621 
	9 chars			1254 
       10 chars			2075 
       11 chars			1215 
       12 chars		 	 753 
       13 chars			 646 
       14 chars			 745 
	
	                amount=28454 
	
    TWNIC just accept 2 to 14 BIG5 chars in a Chinese Domain Name. Those 
    data are all in local encoding of BIG5 ( or CP950 ). Base on those 
    data, apply them to various ACEs. There are RACE-03 [RACE], BRACE-00 
    [BRACE], LACE-01 [LACE], UTF-6-00 [UTF6], DUDE-02 [DUDE], 
    AMC-ACE-M-00 [AMCACEM], AltDUDE-01 [AltDUDE], AMC-ACE-O-00 [AMCACEO], 
    and AMC-ACE-R-01 [AMCACER].
    
2. Result of each ACE length
    
    The CHN_len is the length of Chinese (BIG5) domain name in byte 
    before apply ACE encoding. All of the data in the same CHN_len, the 
    max_len is the maximum length, the min_len is the minimum length, 
    the aver_len is the averager length of them after apply ACE encoding.

  2.1 AMC-ACE-M

    CHN_len    max_len  min_len  aver_len
    -----------  -------- -------- --------
    	2		 8	 5	 8 
	3		11	 6	11 
	4		17	 8	14 
	5		17	11	17 
	6		21	11	20 
	7		24	13	22 
	8		27	15	25 
	9		30	16	28 
	10		33	18	31 
	11		36	22	34 
	12		39	19	37 
	13		42	21	40 
	14		45	23	43 

  2.2 AMC-ACE-O

    CHN_len    max_len  min_len  aver_len
    -----------  -------- -------- --------
	2		 8	 5	 8 
	3		12	 6	11 
	4		20	 9	15 
	5		20	11	18 
	6		24	11	22 
	7		27	13	25 
	8		31	15	29 
	9		35	16	32 
	10		39	18	36 
	11		42	24	38 
	12		46	19	41 
	13		50	21	44 
	14		54	23	48 

  2.3 AMC-ACE-R

    CHN_len    max_len  min_len  aver_len
    -----------  -------- -------- --------
	2		 8 	 5	 8 
	3		12 	 6	12 
	4		20 	 9	16 
	5		20 	11	19 
	6		24 	11	23 
	7		28 	13	26 
	8		32 	15	30 
	9		36 	16	34 
	10		40 	18	38 
	11		44 	24	41 
	12		48 	19	44 
	13		52 	21	48 
	14		56 	24	51 

  2.4 AltDUDE

    CHN_len    max_len  min_len  aver_len
    -----------  -------- -------- --------
	2		 8	 5	 8 
	3		12	 6	11 
	4		20	 8	16 
	5		20	13	19 
	6		24	11	23 
	7		28	14	26 
	8		32	15	30 
	9		36	18	34 
	10		40	21	38 
	11		44	26	41 
	12		48	26	46 
	13		52	25	48 
	14		56	30	53 

  2.5 BRACE

    CHN_len    max_len  min_len  aver_len
    -----------  -------- -------- --------
    	2		 7	 5	 7 
	3		10	 7	10 
	4		17	 8	14 
	5		17	11	17 
	6		20	11	20 
	7		23	13	23 
	8		28	14	26 
	9		30	15	30 
	10		33	17	33 
	11		36	22	36 
	12		39	18	39 
	13		42	20	42 
	14		46	23	46 

  2.6 DUDE

    CHN_len    max_len  min_len  aver_len
    -----------  -------- -------- --------
    	2		 8	 5	 8 
	3		12	 6	11 
	4		20	 8	16 
	5		20	13	19 
	6		24	11	23 
	7		28	15	26 
	8		32	15	30 
	9		36	18	34 
	10		40	21	38 
	11		44	27	41 
	12		48	26	46 
	13		52	25	48 
	14		56	30	53 

  2.7 LACE

    CHN_len    max_len  min_len  aver_len
    -----------  -------- -------- --------
    	2		 8	 7	 8 
	3		12	 8	12 
	4		18	10	15 
	5		18	18	18 
	6		21	16	21 
	7		24	21	24 
	8		31	23	28 
	9		31	24	31 
	10		34	26	34 
	11		37	34	37 
	12		40	29	40 
	13		44	31	44 
	14		47	36	47 
  
  2.8 RACE

    CHN_len    max_len  min_len  aver_len
    -----------  -------- -------- --------
    	2		 8	 5	 8 
	3		12	 7	12 
	4		18	 8	15 
	5		18	18	18 
	6		21	20	21 
	7		24	24	24 
	8		31	28	28 
	9		31	31	31 
	10		34	34	34 
	11		37	37	37 
	12		40	40	40 
	13		44	44	44 
	14		47	47	47 

  2.9 UTF-6

    CHN_len    max_len  min_len  aver_len
    -----------  -------- -------- --------
    	2		 8	 5	 8 
	3		12	 6	12 
	4		20	 9	16 
	5		20	14	20 
	6		24	14	24 
	7		28	18	28 
	8		32	20	32 
	9		36	21	36 
	10		40	23	40 
	11		44	30	44 
	12		48	28	48 
	13		52	29	52 
	14		56	33	56 

3. Result of each ACE conversion speed

		UTF-6	RACE	LACE	BRACE	DUDE	ALTDUDE	
	MAX	0.80 	0.75 	0.82 	0.86 	0.74 	0.70 	
	MIN	0.56 	0.55 	0.52 	0.62 	0.53 	0.53 	
	AVERAGE	0.68 	0.64 	0.62 	0.73 	0.64 	0.62 	

		AMC-ACE-M	AMC-AMC-O	AMC-ACE-R
	MAX	1.12 		1.92 		0.99 
	MIN	0.86 		1.69 		0.67 
	AVERAGE	0.98 		1.81 		0.82 

4. Summary of the result

    All the ACE max_length is less than 64, because the Chinese 
    Domain Name is limited from 2 to 14 BIG5 chars. For those sample
    data, the result of LENGTH and SPEED, it seems the LACE and RACE 
    are better than others.
        
5. Acknowledgements

    This ACE evaluation testing tool was provided by JPNIC. 
    TWNIC provide the real registered Chinese ( BIG5 ) domain names.
    Hsu Nai-Wen <[email-masked]> and TWNIC MDNS technical team give 
    a lot of suggestion.            

6. Author's Address

    Abel Yang
    Taiwan Network Information Center (TWNIC)
    4F-2, No. 9, Sec. 2, Roosevelt Rd., Taipei, 100 Taiwan.
    Email: [email-masked]
    Tel: +886-23411313#505

    Erin Chen
    Tel: +886-23411313#502

7. References

    [RFC1035]  "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
               RFC1034, Nov 1987, P. Mockapetris
    [RACE]     "RACE: Row-based ASCII Compatible Encoding for IDN",
               draft-ietf-idn-race-03.txt, Nov 2000, P Hoffman
    [BRACE]    "BRACE: Bi-mode Row-based ASCII-Compatible Encoding
   	       for IDN version 0.1.2"
               draft-ietf-idn-brace-00.txti, Sep 2000, A Costello
    [LACE]     "LACE: Length-based ASCII Compatible Encoding for IDN"
               draft-ietf-idn-lace-01.txt, Jan 2001, M Davis, P Hoffman
    [UTF6]     "UTF-6 - Yet Another ASCII-Compatible Encoding for IDN"
               draft-ietf-idn-utf6-00, Nov 2000, M Welter, B Spolarich
    [DUDE]     "Differential Unicode Domain Encoding (DUDE)"
               draft-ietf-idn-dude-02.txt, Jun 2001, M Welter, 
	       B Spolarich, A Costello
    [AMCACEM]  "AMC-ACE-M version 0.1.0"
               draft-ietf-idn-amc-ace-m-00.txt, Feb 2001, A Costello
    [AltDUDE]  "AltDUDE version 0.0.2"
               draft-ietf-idn-altdude-00.txt, Mar 2001, A Costello
    [AMCACEO]  "AMC-ACE-O version 0.0.3"
               draft-ietf-idn-amc-ace-o-00.txt, Mar 2001, A Costello
    [AMCACER]  "AMC-ACE-R version 0.2.1"
               draft-ietf-idn-amc-ace-r-01.txt, May 2001, A Costello
    [AMCACEV]  "AMC-ACE-V version 0.1.0"
               draft-ietf-idn-amc-ace-v-00.txt, May 2001, A Costello
    [AMCACEW]  "AMC-ACE-W version 0.1.0"
               draft-ietf-idn-amc-ace-w-00.txt, May 2001, A Costello
    [MACE]     "MACE: Modal ASCII Compatible Encoding for IDN"
               draft-ietf-idn-mace-00.txt, Jun 2001, M Ishisone, Y Yoneya
    [LDUDE]    "Improving ACE using code point reordering v0.9"
               draft-ietf-idn-lsb-ace-00.txt, Jun 2001, Soobok Lee
    [MDNKIT]   "Multilingual Domain Name tool Kit",
               http://www.nic.ad.jp/jp/research/idn/mdnkit/download/
    [NAMEPREP] "Preparation of Internationalized Host Names",                 
               draft-ietf-idn-nameprep-03.txt, Feb 2001, P Hoffman, 
	       M Blanchet

---

From: "Adam M. Costello" <[email-masked]>
Date: Fri, 13 Jul 2001 20:57:38 +0000

It is already permissible (I think) for DNS servers to perform more
complex matching than the usual case-insensitive ASCII matching.  For
example, a DNS server implementation could support master file entries
whose keys are regular expressions, and it could compare incoming
requests to those patterns.  For example, it could allow:

foo-?(two|2)   A   1.2.3.4

to be used as shorthand for:

foo2      A   1.2.3.4
footwo    A   1.2.3.4
foo-2     A   1.2.3.4
foo-two   A   1.2.3.4

Similarly, if a DNS server implementation wants to perform
simplified/traditional Chinese matching, or matching of names encoded
in alternate charsets, isn't it already allowed to do so?  Is there any
need to standardize this?

Note that using such a feature will cause problems at higher layers,
because clients won't know the matching rules.  For example, if I
follow a link to www.foo2.net, and later follow a different link to
www.foo-two.net, the link will not be colored as visited.  If I tell
my browser to accept cookies from foo2.net, it won't know to also
accept cookies from foo-two.net.  Same problem with SSL certificates.
Therefore it would probably be desirable to deal with extended matching
not only in the DNS server but also at higher layers.  In these
examples, one might want the HTTP server to redirect requests from the
alternate server names to a single preferred server name.

AMC

---

From: Martin Duerst <[email-masked]>
Date: Sat, 14 Jul 2001 11:23:06 +0900

>requests to those patterns.  For example, it could allow:

Yes, they could. But how would that work with ACE?
It would be a terrible headache. That's one of ACE's
main problems.

Regards,   Martin.