Subject: [idn] Prohibit CDN code points

From: "Kenny Huang" <[email-masked]>
Date: Sun, 20 Jan 2002 10:29:03 +0800

Dear IETF members

It seems that the CDN architecture proposal I presented in the IETF 
52nd meeting didn't capture significant consensus from the people 
of the Working Group. Some may claim that the proposed 
architecture may result in  "a partial solution to a partial problem", 
or "delay of IDN development",...,etc. If there is no support in the 
the proposal, the Chinese domain name issue remains an unresolved 
issue. If the Working  Group feels the problem is too complicate to 
be solved,  I have to  propose the final architecture as the following:
 
   ---------------------------------------------
   |             NamePrep                             |
   ---------------------------------------------
                             |  
   ----------------------------------------------------------------
   |    Prohibit code points :                                            |
   |    (4E00-9FAF)     Unified Ideographs                     |
   |    (3400-4DBF)   Unified Ideographs Extension A   |
   -----------------------------------------------------------------
                             |
   ---------------------------------------------
   |             Punycode                          |
   ---------------------------------------------
  
It implies there will be no Chinese domain name services until there 
is other solution proposed and agreed by the Working Group. 
I feel sorry to Chinese community, but by temporarily excluding the 
Chinese domain name service, the Working Group can ensure that 
the IDN progress is not hindered by CDN development. 
  
Best Regards
   
Kenny Huang

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 20 Jan 2002 09:17:47 -0800

>is other solution proposed and agreed by the Working Group.

The WG should note that this proposal prohibits Japanese and Korean 
names as well.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "ben" <[email-masked]>
Date: Sun, 20 Jan 2002 12:30:01 -0500

Hi Kenny,

>the IDN progress is not hindered by CDN development.

Although it may seem like a good suggestion at first, is that option
realistically possible?

My knowledge in Japanese and Korean is very limitted, but from what I
have learned from the past discussions in this WG... it is that CJK
share many of the same code points.  Is it possible to let the
Japanese and Korean domains names go forward and prohibit Chinese
domain names?

Thanks,
Ben

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 20 Jan 2002 10:00:00 -0800

At 12:30 PM -0500 1/20/02, ben wrote:
>Is it possible to let the

No, and that one of the main problems that the CDN community faces. 
In the ISO/IEC 10646 repertoire (which is the same as the Unicode 
repertoire), it is impossible to differentiate between Chinese 
characters and Korean characters and Japanese characters. Thus, any 
proposal to remove the characters for one language removes them for 
all.

--Paul Hoffman, Director

---

From: [email-masked] <[email-masked]>
Date: Mon, 21 Jan 2002 22:58:42 +0800

It is possible if  we assume the ccTLD implied the language used .  So, they
can be treated with different way based on the ccTLD name implied language.
Now,  only gTLD has this problems.  If  only ASCII ".com" is used, it can
not identify which language is used in hostname part. But if  ML-gTLD is
available , the ML(com) can be classfied by the implied language characters
in ML(com). Especially , ML(gTLD) is very small  and can be predefined .

L.M.Tseng
----- Original Message -----
From: "Paul Hoffman / IMC" <[email-masked]>
To: "ben" <[email-masked]>; "Kenny Huang" <[email-masked]>;
"IETF-IDN" <[email-masked]>
Sent: Monday, January 21, 2002 2:00 AM
Subject: Re: [idn] Prohibit CDN code points

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 21 Jan 2002 16:45:51 +0100

--On 2002-01-21 22.58 +0800
"=?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?="
<[email-masked]> wrote:

> It is possible if  we assume the ccTLD implied the language used .

What language are they to use in Canada? Sweden?

   paf

---

From: [email-masked] <[email-masked]>
Date: Mon, 21 Jan 2002 23:54:06 +0800

Dear Patrik Fältström:
         Some ccTLD is like ".com" ,  in that country/region thare are many
language used , so they can use ML(ccTLD)
to mean what language is predefined implicitly.

L.M.Tseng
----- Original Message -----
From: "Patrik Fältström" <[email-masked]>
To: "tsenglm@è¨ˆç¶²ä¸­å¿ƒ.ä¸­å¤§.tw" <[email-masked]>; "ben"
<[email-masked]>; "Kenny Huang" <[email-masked]>; "IETF-IDN"
<[email-masked]>; "Paul Hoffman / IMC" <[email-masked]>
Sent: Monday, January 21, 2002 11:45 PM
Subject: Re: [idn] Prohibit CDN code points

---

From: "ben" <[email-masked]>
Date: Mon, 21 Jan 2002 11:10:30 -0500

Hi Tseng / Paul,

I like Tseng's idea for a new type of ML-gTLD very very very very very
much!  :-)

Unfortunately, I don't think it answers the problem Paul and I brought
up- which is what to do about the *current situation* with the gTLD
that has registered domains in Chinese, Japanese, Korean (even a
mixture of them) if infact we want to prohibit CDNs and let the other
IDNs move forward.

Thanks,
Ben

----- Original Message -----
From: "[email-masked]" <[email-masked]>
To: "ben" <[email-masked]>; "Kenny Huang" <[email-masked]>;
"IETF-IDN" <[email-masked]>; "Paul Hoffman / IMC" <[email-masked]>
Sent: Monday, January 21, 2002 9:58 AM
Subject: Re: [idn] Prohibit CDN code points

> It is possible if  we assume the ccTLD implied the language used .
So, they

---

From: "Masahiro Sekiguchi" <[email-masked]>
Date: Tue, 22 Jan 2002 09:37:53 +0900

> can be treated with different way based on the ccTLD name implied language.

No, assuming _language_ by ccTLD is a bad idea.

We only need to assume each ccTLD implies a well-defined
set of rules of mapping/matching domain names.

One of the difficulty IDN WG is facing is one universal
set of such rules appropriate all-over-the-world.  By reducing
applicable area of each set of rules smaller, it will be far
more easier to find the rules.

My scenario is as follows:

(1) IDN WG defines a basic set of rules with several options.
    One of the options can be: enable/disable SC/TC mapping,
    for example.

(2) Each TLD registry defines and propergates a concrete
    set of selections among those options, to be used
    for the domain names under the TLD.

    For example, .cn domain can say "SC/TC mapping must be 
    enabled for .cn" if it considers that decision serves the
    .cn domain name users best.  If another domain, say .us,
    finds contrary, it can say "SC/TC must be disabled for .us".

(3) The set of selected options for each TLD must be somehow
    notified to all DNS clients.  IDN WG must develop a
    reasonable way to allow it.  One possibility is to use
    DNS query against the TLD for a special RR.  (This is
    just an example idea.)

(4) DNS clients implements NAMEPREP module as a "parameterized"
    algorithm.  The parameters here is the set of selected
    options.

Note that the intention of this optional (or parameterized)
approach is to make negotiation/compromise easier.  If a ccTLD
considers almost all users of that particular ccTLD uses
same language, the ccTLD can use a set of options optimized for
taht language.  If it finds its users use relatively small 
number of languages, the ccTLD can compromise to find a set 
of rules suitable for those small number of languages.  In case
a ccTLD finds its user communities are so broad, it can choose
a set of neutral options that is *not* best for anybody but is
not harmful either.

The point is: assuming "a ccTLD is tied to a language" is
infeasible, but "to a set of processing rules" looks OK.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 22 Jan 2002 07:59:21 +0100

>     finds contrary, it can say "SC/TC must be disabled for .us".

This will not work because _all_ DNS servers in the world need to be able
to fulfil matchings according to the rules the .cn TLD decides. That in
turn means that all DNS servers need to have matching rules which is the
sum of _all_ rules _all_ TLD's define (and subdomains to TLDs etc, because
of course I want a special matching rule for my subdomain of .com!).

This in turn leads by definition to one to me very complex matching
algorithm which is context dependent and not one for each domain in the
world.

Noone have come up with such an algorithm.

And, one thing DNS likes is when one label have the same matching algorithm
regardless of what "neighbour" labels are in the DNS packet. Leaving this
strategy and have different matching rules for the same octets depending on
context is a _very_ big change to all existing DNS implementations.

Don't go there.

   paf

---

From: [email-masked] <[email-masked]>
Date: Tue, 22 Jan 2002 17:31:41 +0800

----- Original Message -----
From: "Patrik Fältström" <[email-masked]>
To: "Masahiro Sekiguchi" <[email-masked]>; "IETF-IDN"
<[email-masked]>
Sent: Tuesday, January 22, 2002 2:59 PM
Subject: Re: [idn] Prohibit CDN code points

> of course I want a special matching rule for my subdomain of .com!).
        I  think  "the matching rule of server" and "the SC/TC mapping must
be enable foe .cn " in client 's side before IDNA/nameprep  is different
approach.
        The switch in client based on ccTLD is the similar function of
nameprep( mapping , normalization and prohibit).
TC/SC character equivalence mapping is similar to  the mapping of  UNICODE
Alphabet  map  it to its counterpart of ASCII  alpnabet .  The switch will
control the TC/SC equivalence mapping is enabled and the result can be
passed and processed by  nameprep then send to Punny code encoder or not.
       If  TC/SC script should be indicated which one of  it correctly in
the .cn Domain , a  signal information per script can be associated with the
equivalence mapped code and they are passed to Punny code encoder to encode
it with case anotation for non-basic-code-point  part.
       The LDH DNS server still use one simple matching rule for any domain.

---

From: "Edmon" <[email-masked]>
Date: Tue, 22 Jan 2002 15:51:04 -0500

Hi Patrik,

Additional and optional character equivalence preparation by zone is
possible.

----- Original Message -----
> to fulfil matchings according to the rules the .cn TLD decides. That in

This is not true. As long as the .cn DNS does the matching internally and
provide a consistent response, why would "all" servers in the world need to
be able to fulfil the matchings?  If you are arguing how the application
then use the information to connect to the destination server, thats another
issue.  But by zone rules are possible.

> context is a _very_ big change to all existing DNS implementations.

I agree with you on this.  But I dont think what is being discussed is
"neighbour-label" dependent matching rules, instead it is the ability for
zone operators to decide which options they could pick and choose from to do
internal matching.  And I think it is agreeable that it makes sense to have
a standardized list of options for operators to choose to implement.

Edmon

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 23 Jan 2002 09:39:17 +0100

Hi Patrik,

But very undesirable. It will be very had to explain why the matching
is different in different zones. And I predict that when there are
conflicts about the names and they are caused by these different
matching rules, the lawyers will care less about the explanation.

Don't go this road!

	jaap

---

From: Erin Chen <[email-masked]>
Date: Wed, 23 Jan 2002 17:58:09 +0800

Dear Paul,

In the other word,  if  do not prohibits CJK code points,
the standard also shall hurt CDN requirements.

So, We have no choice but to prohibit CJK code points temperarily.
Untill the proper or better rule comes out which will not let CJK hurt 
each other..

Erin Chen

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 23 Jan 2002 11:08:19 +0100

--On 2002-01-22 15.51 -0500 Edmon <[email-masked]> wrote:

> provide a consistent response, why would "all" servers in the world need
> to be able to fulfil the matchings?  If you are arguing how the
> application then use the information to connect to the destination
> server, thats another issue.  But by zone rules are possible.

No, because you will have a caching DNS server which also have to be able
to do matchings for things in the .cn TLD. This means that any caching DNS
server have to have the complete set of rules used in all zones in the DNS.

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 23 Jan 2002 12:43:19 +0100

> Untill the proper or better rule comes out which will not let CJK hurt

The problem with CJK codepoints and the SC/TC problems everyone talks about
is the unification which is done in the Unicode character set.

Just because in Unicode, the same character have the same codepoint
regardless of the language for CJK codepoints, there is no way to compare
two codepoints and say that they sometimes are different and sometimes not.

The Unicode tables are approved by the Unicode Consortium and ISO, and we
can not in the IETF "undo" that unification procedure.

This is the reason why we rely on other standard organizations to do "the
right thing". They have defined that when only comparing two characters, a
given codepoint in a normalized Unicode string is to be equal (or not
equal) with according to the matching rules Unicode are defining.

This means further that if one enter a string in Unicode, one will _NOT_
know whether SC or TC was used.

So, given this unification which _already_is_a_done_deal_, the matching
algorithms which are more "clever" have to have metadata part from the
query string itself, such as language, culture, original script used etc.

We can _not_ do these context-sensitive matchings in the DNS for reasons
which have been stated on this mailing list for the last year, over and
over and over again.

Instead, the IETF have started (in the Applications Area) look into a
lookup system which _can_ handle context-sensitive matchings.

So, given Unicode as character set, context-sensitive matchings have to be
done where one can pass around a context and not only a query string.

And this is NOT the DNS.

    paf

---

From: [email-masked] <[email-masked]>
Date: Wed, 23 Jan 2002 19:50:42 +0800

----- Original Message -----
From: "Patrik Fältström" <[email-masked]>
To: "Edmon" <[email-masked]>; "Masahiro Sekiguchi" <[email-masked]>;
"IETF-IDN" <[email-masked]>
Sent: Wednesday, January 23, 2002 6:08 PM
Subject: Re: [idn] Prohibit CDN code points

> server have to have the complete set of rules used in all zones in the
DNS.

         It is right, cache DNS will cause some problems. But the caching
DNS need not only to have the complete set of rules used in authorized zone
DNS . If  the caching DNS use the matching rule with the capability of
differentiation  more than authorized zone server, it will work too.
         It is one of the possible solution in some particular condition but
this is not the current issue of this thread.
L.M.Tseng

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 23 Jan 2002 13:28:09 +0100

--On 2002-01-23 19.50 +0800
"=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?="
<[email-masked]> wrote:

> DNS need not only to have the complete set of rules used in authorized
> zone DNS . If  the caching DNS use the matching rule with the capability
> of differentiation  more than authorized zone server, it will work too.

No, that is wrong. The caching server need to know the matching rules, or,
you might do matching in the cache which should not be done because of a
local rule in the domain.

   paf

---

From: YangWoo Ko <[email-masked]>
Date: Wed, 23 Jan 2002 21:47:33 +0900

> know whether SC or TC was used.

Dear Patrik Faltstrom,

Your last statement does not exactly describe TC/SC issue. Following may
explain TC/SC issue better;

"If one enter a string in Unicode, one may or may not know whether TC or
SC was used. It depends both on his language in mind when entering that 
string and on his knowledge about characters."

Dear all members,

What about having additional prefix(es) for extension like TC/SC issue ? 
For example, az-- for normal IDNA and bz-- for chinese-extension IDNA 
and so forth. It may serve as an context information or language tag.

Regards

-- 
/*------------------------------------------------
YangWoo Ko : [email-masked]
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/

---

From: YangWoo Ko <[email-masked]>
Date: Wed, 23 Jan 2002 21:57:28 +0900

Dear Tseng,

Please correct me if I am wrong. As far as I know, you are not going to 
add more rules to DNS server. Instead, some IDNA implementations may have 
more features to comply with CDN requirement. But, this specific thread
is about whether it is good or not to make DNS server having language 
depending features. So, your answers on this specific thread made me
be totally confused.

My best regards

On Wed, Jan 23, 2002 at 07:50:42PM +0800, [email-masked] wrote:
> From: "Patrik F??ltstr??m" <[email-masked]>

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 23 Jan 2002 14:18:01 +0100

> string and on his knowledge about characters."

Correct.

> and so forth. It may serve as an context information or language tag.

How do you match between one string which uses az--<foo>.com and
bz--<foo>.com where "<foo>" stands for the term "foo" but encoded?

And, yes, you can do this, but as i have pointed out before, this means
every server needs to know about all matching algorithms.

I.e. if you open the box of "problems" with Unicode, you will find that the
SC/TC problem is only one of them. Only one. I guess we have some 20-30
other problems which are similar to the SC/TC, i.e. problems because of
unification or non-unification in Unicode.

So, you will see an explosion of matching rules.

Reason we see this about SC/TC is that that happen to be the problem space
we discuss at the moment. We could aswell discuss the problems with
adiaeresis in the countries and languages which uses it.

My conclusion is the same, every server need to have knowledge about how to
handle all encodings.

   paf

---

From: YangWoo Ko <[email-masked]>
Date: Wed, 23 Jan 2002 23:24:45 +0900

> every server needs to know about all matching algorithms.

I am talking about IDNA. With IDNA, we do not add matching algorithm
to any server. Some client may try "az--" and it fails, it may try 
"bz--" with TC/SC feature-enabled preprocessing, while others only 
try "az--". I know this may look quite ugly. But, current IDN proposal 
seems premature in terms of internationalization at least from the Chinese 
people's point of view.

Allowing Unicode be used where only ASCII was used before is not enough 
for internationalization. We should prepare an enough room in which
localization can be done while complying with internationalized standards.

> SC/TC problem is only one of them. Only one. 

Yes, I totally agree.

> I guess we have some 20-30

Why are we going to hide and ignore problems even though we know they are
there ?

> My conclusion is the same, every server need to have knowledge about how to

My conclusion is the same with yours.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 23 Jan 2002 16:49:10 +0100

--On 2002-01-23 23.24 +0900 YangWoo Ko <[email-masked]> wrote:

> seems premature in terms of internationalization at least from the
> Chinese  people's point of view.

The problem occur when you use a language like for example Swedish. I can
type something in Swedish, and it should match something in Norwegian. It
might also match something in German, and English. What about "color" and
"colour" matching when you use US-english and UK-englisg?

So, my resolver library encode in some IDNA-like fashion the query in all
of the languages above, and then try them one at a time until a match is
found.

I call that guessing, and not something the DNS is made for, very efficient
in doing and something we in the IETF repeatedly have said "No" to many
times.

Just because the DNS is a lookup system where a client calculate a key,
that key is sent to the mesh of servers, and a result is returned.

The alternative would be to have the servers understand that UK-Enlish and
US-English is "almost" the same, and they are able to match ab-<color> with
bc-<colour>. Should ab-<colour> match bc-<colour>? If not, then ab-<color>
is the same as bc-<colour> which in turn is different from ab-<colour>.
This means we will/can get a registrant which register ab-<colour> and one
which register bc-<colour> but noone at that time register ab-<color>
because bc-<colour> is already taken, and we require global uniqueness.

I.e. if you _want_ to go down this path, you should look at the RFC's about
definition of lanaguge codes, and think about how you should do something
which can handle those languages. Then, hopefully, you will be convinced
that this is not a path that can be followed.

Multiple lookup in DNS is not something that will be accepted, and multiple
matching algorithms will not work either.

> localization can be done while complying with internationalized standards.

You have to differ between localization and internationalization. It is
wellknown that IDN is _not_ about localization.

>> I.e. if you open the box of "problems" with Unicode, you will find that
>> the SC/TC problem is only one of them. Only one. 
> 
> Yes, I totally agree.
> 

Because you can not solve them using Unicode and non-context-matchings
which is what we do in DNS.

>> My conclusion is the same, every server need to have knowledge about how
>> to handle all encodings.
> 

Good.

  paf

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Jan 2002 07:47:12 -0800

>can not in the IETF "undo" that unification procedure.

A variation to the cliche "if the only tool you have is a hammer, then 
everything starts looking like a nail" applies to this working group:  If 
the only venue you have is an IETF working group, then everything starts 
looking as if it is within scope of the working group.

As Patrik has once again reminded everyone, this entire discussion is 
entirely outside the scope of this working group.  We can choose to use 
Unicode or not, but we cannot "fix" it.

The task of this working group is to find a way for the DNS to use 
character strings that are more diverse than ASCII.  As has been often 
explained, character strings are not the same as words.  Comparing strings 
is different from comparing words.

d/

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

---

From: [email-masked] <[email-masked]>
Date: Thu, 24 Jan 2002 00:05:01 +0800

Dear Ko:
        You are right. In current discussion , my proposal is not interested
in DNS server approach. I talk it , because some people worry about the
prohibitation of CDN code points in IDNA will let some area can not work.
So, I give some solutions to let them can be done by area/language TLD
dependent name solving to reduce the troubles of CDN delay.
        The second reason is that some client has the caching feature, but
the caching client actually need not only just the same matching rule as
authorized zone DNS if we assume  this client will query the authorized zone
DNS at first or refresh time. I think this description can help to remove
some misunderstanding of current BIND DNS cache. For example:
1.Assume authorized zone server is case insensitive and the record:
bq--xyz   A  1.2.3.4

2.Assume client is case sensitive in matching  records in local cache. These
query will be get and copied result from authorized server.
bq--xYz   A  1.2.3.4
bq--XYZ   A  1.2.3.4
bq--xyz   A  1.2.3.4

  That means if caching client has capability of differentiating than zone
server will still work.
  To force the query information to lower case and store it in local client
is not so necessary to a case insensitive DNS server.
That is my point about IDNA nameprep.

L.M.Tseng
----- Original Message -----
From: "YangWoo Ko" <[email-masked]>
To: "IETF-IDN" <[email-masked]>
Sent: Wednesday, January 23, 2002 8:57 PM
Subject: Re: [idn] Prohibit CDN code points

> > > > This is not true. As long as the .cn DNS does the matching
internally
> > and
zone

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 23 Jan 2002 17:19:37 +0100

--On 2002-01-23 07.27 -0800 "Mark Davis (jtcsv)" <[email-masked]>
wrote:

> The TC/SC problem can be dealt with by means of the registration of a
> small number of additional names. Little different in kind from
> registering both theatre.com and theater.com, or aarborg.com and
> a<ring>rborg.com. While theoretically someone could have 5-character name
> with 32 combinations of TC/SC, in practice nobody has proven this to be a
> real problem, or even provided any evidence whatsoever that clients will
> in fact be confused.

Exactly!

Thanks Mark for bringing this up again.

I forgot to point this out.

  paf

---

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

----- Original Message -----
From: "YangWoo Ko" <[email-masked]>
To: "IETF-IDN" <[email-masked]>
Sent: Wednesday, January 23, 2002 10:24 PM
Subject: Re: [idn] Prohibit CDN code points
...
> localization can be done while complying with internationalized standards.
          I  totally agree with these , whether the UNICODE is unified or
not , it is not the issue in this thread, we want to know where is the
interface or room in IDNA and through which  the localization results and
information  can be passed.

L.M.Tseng

---

From: hoho <[email-masked]>
Date: Thu, 24 Jan 2002 00:55:19 +0800

Yes, Unicode is the source of problems for IDNs with Han characters. But, did
anyone
ask IDN WG to undo anything? Why is it a problem here?

If you propose not to adopt Unicode as part of IDNA as an alternative of doing
nothing
to help people using Han characters. We appreciate that.

-- Janming

Dave Crocker 寫入：

> At 12:43 PM 1/23/2002 +0100, Patrik F鄟tstr闣 wrote:

---

From: hoho <[email-masked]>
Date: Thu, 24 Jan 2002 00:59:43 +0800

There is a big difference between "IDNA did not solve all our problems" and
"IDNA
creates problem for our community".

-- Janming

---

From: Yoshiro YONEYA <[email-masked]>
Date: Thu, 24 Jan 2002 02:30:39 +0900 (JST)

hoho,

From: hoho <[email-masked]>
Subject: Re: [idn] Prohibit CDN code points
Date: Thu, 24 Jan 2002 00:55:19 +0800

> ask IDN WG to undo anything? Why is it a problem here?

You should read recent 4-6 months' mail archive of this mailing list.
Unicode is only one universal standard we can refer.

-- 
Yoshiro YONEYA <[email-masked]>

---

From: "Edmon" <[email-masked]>
Date: Wed, 23 Jan 2002 13:19:55 -0500

----- Original Message -----
> server have to have the complete set of rules used in all zones in the
DNS.

But caching servers only cache the result of a query.
for example a domain request
<A><A'>.example
the .example ns would internally match it with
<a><a>.example
and reply with a positive response.
the caching server will therefore cache
<A><A'>.example
with the response.
If you are asking what happens if another request comes:
<a><A'>.example
then the answer is simple, it will consult the .example server again,
then it will cahce
<a><A'>.example
with the response.
So, I dont see why all the servers in the world needs to be able to handle
all additional matching rules.

Edmon

---

From: "Edmon" <[email-masked]>
Date: Wed, 23 Jan 2002 13:23:36 -0500

Hi Jaap,
But I dont think this is the real issue.  What I hear is that people want to
have an option to implement it and they want a set of standardized options.
I believe our job is to create the standardized set of options and allow
implementors to pick and choose.  If you think it is advisable to caution
the implementors of these options, that is another issue.
Edmon

----- Original Message -----
From: "Jaap Akkerhuis" <[email-masked]>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Jan 2002 10:35:35 -0800

At 12:29 AM 1/24/2002 +0800, 
>information  can be passed.

A standard that is focused on international interoperability cannot be the 
place for localization.

So, the place for what you are seeking is outside IDNA.  In terms of 
architecture, it is at a layer above IDNA.

d/

----------

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 23 Jan 2002 21:10:32 +0100

> all additional matching rules.

It's not that easy. The result coming back is called an RR-Set, which means
all records which have the same owner. The responses are always treated in
groups of RR-Sets.

Now, given that we have one RR-Set which has different content on an
authoritative server from a caching server, read your favourite RFC's about
DNS Security.

Just don't go there.

     paf

---

From: "Edmon" <[email-masked]>
Date: Wed, 23 Jan 2002 15:50:13 -0500

So, at the end of the day, we point back to DNS Sec which creates the
problem.
I understand and know that there are potential problems but there are
possible solutions as well.  I think there are still a number of outstanding
issues in DNS Sec anyway.  So if this does create a potential issue,
shouldnt we raise the issue instead of shy away from it just because?  Is
this a positive engineering design practice?
Therefore, please dont say that it is not possible and advertise it as such
just like that.  It is possible but we just need to also take care of the
DNS Sec potential issues.
One of the possibility obviously is signing on the fly (perhaps less
advisable), the other the use of opt-in (still in progress... problematic
domains will have to opt-out), and thirdly to have sig rrs for all
permutations (readily possible).  There are more possibilities I believe, we
just need to document them for the implementor to choose from or advise one
particular method.  Afterall, I think it is important that we have a
standardized set of options to deal with the problem at hand (which is
perceived character equivalancy) and it should be within the DNS, but not
necessarily affecting the overall protocol.
With by Zone optional charprep mechanisms, we can achieve this.
Edmon

----- Original Message -----
From: "Patrik Fältström" <[email-masked]>
To: "Edmon" <[email-masked]>; "Masahiro Sekiguchi" <[email-masked]>;
"IETF-IDN" <[email-masked]>
Sent: Wednesday, January 23, 2002 3:10 PM
Subject: [idn] Re: Optional & Additional Character Equivalence Preparations
by Zone

---

From: Erin Chen <[email-masked]>
Date: Thu, 24 Jan 2002 10:24:44 +0800

Dear Paul,

Yes, You point out the key point. The problem is caused by  Unicode 
ambiguity.

Because of Unicode ambiguity, many critical problems will comes out:
the registration dispute of 2^n, the delegation/resolution inconsistent, 
the naming
uncertainty.

CDN requirements are extremely required in CDN users daily live.
All of the problems caused by Unicode ambiguity shell hurt CDN.

Erin Chen

Paul Hoffman / IMC wrote:

> No, and that one of the main problems that the CDN community faces. In 
> the ISO/IEC 10646 repertoire (which is the same as the Unicode 
> proposal to remove the characters for one language removes them for all.
>
> --Paul Hoffman, Director

---

From: hoho <[email-masked]>
Date: Thu, 24 Jan 2002 10:46:46 +0800

Unicode has its own purpose. As their design goal, did Unicode take domain
name considerations into account?

Unicode has their uniqueness and impacts in many application. We are reminding
the WG that it is abusing Unicode by using it as the basis of domain name
delegation and resolution.

For those who claim to use Unicode as it is, hope you don't mind to wait until
Unicode
Consortium solves naming ambiguity problems associated with the IDNA proposals.

Please do not pretend that victims of IDNA do not exist.

-- Janming

---

From: YangWoo Ko <[email-masked]>
Date: Thu, 24 Jan 2002 12:02:25 +0900

Dear Dave Crocker,

Thank you for your answer.

> architecture, it is at a layer above IDNA.

Your argument is totally correct. But, as far as TC/SC issue is concerned,
we are not dealing with 0 or 1 issue. Please, let me quote from Paul 
Hoffman's I-D draft-hoffman-i18n-terms-04.txt.

      ... The better internationalized an application is,
      the easier it is to localize it ...

I want to rephrase it;

      ... The poorer internationalized an application is,
      the harder (or even impossible) it is to localization it ...

As I have not yet surveyed TC/SC issue enough to make a solid conclusion, it
seems to me that we are going to come up with very poorly internationalized
standard.

My best regards

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Jan 2002 20:40:13 -0800

>seems to me that we are going to come up with very poorly internationalized

Forgive me, but you are confusing "application" with "protocol".

d/

----------

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 24 Jan 2002 11:37:47 +0100 (CET)

> permutations (readily possible).

Edmon,

If the DNS servers don't care about potential DoS attacks and having on-line
keys then signing on the fly could work. But that is a huge "if".
The DoS attack is that anybody can send DNS queries to have the DNS server
spend all its CPU generating signatures on the fly.
Sure sounds like a bad design from a security and robustness perspective.

I don't understand what "opt-in" has to do with IDN. Could you please explain?

Your third idea (SIG RRs for all permutations) has a natural follow-on:
If you have enough memory/storage for the large SIG RRs for all permutations
then the additional memory/storage for the underlying RRs for all permutations
will be very small. So in practise this sounds like creating all permutations
in the zone file e.g. at registration time.
That (or just a subset of all permutations picked at registration time) has the
benefit of not requiring any changes to the DNS server software.

   Erik

---

From: "Edmon" <[email-masked]>
Date: Thu, 24 Jan 2002 11:14:46 -0500

----- Original Message -----
From: "Erik Nordmark" <[email-masked]>
> Sure sounds like a bad design from a security and robustness perspective.
Which is why I said it is not advisable.  But it is a possibility.

> I don't understand what "opt-in" has to do with IDN. Could you please
explain?

Multilingual names that have character equivalency issues will have to
opt-out of DNSSEC.

> benefit of not requiring any changes to the DNS server software.

Erik, honestly, I dont have the exact "best" solution yet.  My point is that
there are "possibilities" and we should not rule the entire thing out just
because it might be a bit difficult.  I really want to stop talking about
this subject on this list, but it seems to me very irresponsible, especially
considering that I am an implementor of this technology that I would have to
tell my customers that:
A.example  is NOT the same as A.example
How can I do that?  Any normal person in this world would not accept this,
yet I am creating a system that force them to accept that.  I could step
back and say, "o well, buyers beware", but it just doesnt seem right.  Do
you think it is right?

Edmon

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 25 Jan 2002 09:48:09 +0800

For the same reasons as the thread on CDN, (ie, not of core interest),
this thread is also out of scope so please bring it offline.  I already
give you my comments offline.

Thanks!

-James Seng

----- Original Message -----
From: "Edmon" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: "Patrik Fältström" <[email-masked]>; "Masahiro Sekiguchi"
<[email-masked]>; "IETF-IDN" <[email-masked]>
Sent: Friday, January 25, 2002 12:14 AM
Subject: Re: [idn] Re: Optional & Additional Character Equivalence
Preparations by Zone

> > I don't understand what "opt-in" has to do with IDN. Could you
please
> > That (or just a subset of all permutations picked at registration
time)
> has the

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 25 Jan 2002 13:54:03 +0100 (CET)

> Multilingual names that have character equivalency issues will have to

That shounds like a non-starter.
We need to figure out how to provide better Internationalization of
IETF protocols and we need to make the Internet more secure.
Forcing users to choose between either IDN or secure doesn't accomplish
this.

> because it might be a bit difficult.

I think we've talked about this on the list for two years. Lots of folks
have said "I have an idea" and further exploration on the list or in I-Ds
have determined that when taking the details into account the idea
doesn't fit with the constraints imposed by the DNS and the applications.

So the problem isn't that it is a bit difficult, but that it can't be made
to work given the constraints.
That doesn't make the problem less important - but it means that it doesn't
fit into the DNS. Hence the work on layer 2 where more context can be
taking into account when searching for names.

>  I really want to stop talking about

Isn't much different than MICROSOFT.COM and MICR0S0FT.COM (digit 0 vs. O).

But I think the problem is important. 
But I've come to the conclusion that solving the problem either requires
 - replacing the DNS with something else that can do approximate matching, or
 - building a system on top of the DNS.

I think the vast majority, no matter how important they think the problem is,
don't want to take the risk to the current operational Internet of
a whole-sale replacement of the DNS.
Leaves the layered approach as the only reasonable choice.

  Erik

---

From: [email-masked] <[email-masked]>
Date: Fri, 25 Jan 2002 22:55:08 +0800

Dear  Edmon & Erik:
          Sorry ,  I jump into your discussion. But this is first time,  I
feel there are some honest engineer want to dig the true problem  and not
only announce it is a forbidden area.
----- Original Message -----
From: "Erik Nordmark" <[email-masked]>
To: "Edmon" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; "Patrik Fältström"
<[email-masked]>; "Masahiro Sekiguchi" <[email-masked]>; "IETF-IDN"
<[email-masked]>
Sent: Friday, January 25, 2002 8:54 PM
Subject: Re: [idn] Re: Optional & Additional Character Equivalence
Preparations by Zone

> Forcing users to choose between either IDN or secure doesn't accomplish
              In my personal experimental implementation test and analysis.
I  can make sure current UTF-8 DNS can be modified to work as a ML-DNS with
character equivalency  capability and all of them should to  form a core
tree.  If  these server are work as core server without working as a cache
to non-character-equivalency DNS server, the problems of  mis-cache-data and
authorized tree relation check  can be avoid.

> taking into account when searching for names.
             A  core ML-UTF8-DNS tree is another Layer 2 server with more
character equivalent capability than current edge UTF-8 DNS server. But this
approach  will not follow the layer relation . Actually,  more lower layer
should more capability of  equivalence to form a common base . The  current
IDNA  nameprep  do not follow this rule ,  so it will force LDH-DNS can not
be work as a server with more capability  of  character equivalence . Even
Puny code have support this feature based on ASCII case insensitive
comparision of  LDH-DNS server.

>  - building a system on top of the DNS.

         If  it is out of control , it is no different with  TLD string be
append with an additional domain name in client .
As I  know ,  If  on top of current DNS is need , taking ML-DNS approach as
the layer2 server is more save than other server.

Best regards,

L.M.Tseng

---

From: [email-masked] <[email-masked]>
Date: Sun, 27 Jan 2002 08:59:52 +0800

Dear Dave & all:
----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "tsenglm@è¨ˆç¶²ä¸­å¿ƒ.ä¸­å¤§.tw" <[email-masked]>
Cc: "YangWoo Ko" <[email-masked]>; "IETF-IDN" <[email-masked]>
Sent: Thursday, January 24, 2002 2:35 AM
Subject: Re: [idn] Prohibit CDN code points

> architecture, it is at a layer above IDNA.
               A  layer above IDNA is a cocept view .  A layer above IDNA
may by-pass the lower layer and directly communicate in the wire  if there
are no entry or interface that the above localization module can exchange
the information between them . If  the requirement is neglected  and there
are no way to go ,  the international interoperability will not be keep in
proper way.
               I  think  Japan, Korean and China all want to know where is
the interface they can go thru .

L.M.Tseng