[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Localization issues: (WAS alpha v0.2)



At 10:16 PM 1/24/00 , James Seng wrote:
>Hi Olafur,
>
>Just one general comment on the suggestion. You focus on the way how these are
>handled on the DNS packets and you are right in the sense that these localized
>issues can be solved on the client side, ie
>1. if a language choose to reverse the domain order, they can do so on
>   the user interface level but keep the bits order correct in the packets.
>2. UI can introduce new separate as they wish so long the labels are 
>   encoded accordingly in the packets.
>3. UI can render fonts as they wish from right->left if neccessary so
>   long, once again, the bits order are preserved in the packets.
>
>Looking from this persective, I suppose we can consider all these a UI problem
>and the question now is should IDN work on a requirement for the UI or should
>we focus on requirement on the wire level?
>

You summarize my arguments quite well, now I can give my motivations for 
them. Please excuse me for getting into possible solution spaces but
that is for illustrative reasons only.

I think we need to realize that there are two important but contradicting 
forces pulling on DNS under the IDN umbrella. The first one is
internationalization
which in my mind is the extension of the character set(s) useable in DNS. 
The other is Localization where we want to allow people to use their
own language and character sets to express "destinations". 
At first glance some are arguing for the second one, even at the cost of
DNS meltdown. I think it is important that we are aware of the issues and make
a choice between the options that take this in mind. 

To me Internationalization is important and a fair request. But there
are pitfalls, and I want to bring some of these out in this message. 
One possible solution for IDN is to declare a new DNS domain name type 
(read character set to rest of world) that encodes non US-ASCII on
the wire. 

Fact: In IDN there is does not have to be any relationship of label type
between two adjacent labels in a domain name. 
What this says is that we can have some labels in standard text label type,
some IDN type a and some IDN type b and even binary. (Why anyone will want 
to do this is not important, but I assume that the right most label is always
going to be standard text type (US-ASCII)). 

If we have an IDN name how do we express this name on a billboard or 
business card in such a way that anyone can enter it anywhere in the world? 
Actually there are two questions here 
        1. how do we express the correct label type ? 
        2. how do we express the contents of each one of the labels ? 

If the IDN type allows for certain labels in which the order of "symbols" 
can be reversed between the wire and presentation formats how do we 
express that order to ignorant users and UI's ? 

A possible solution to the second one is to use different label type or a
special 
"symbol" to indicate the order.

Now lets take a step backwards and think about the problem in a little bit 
different way. 

Few hundred years ago different cultures used different systems
for counting and numbers, but by now everyone has evolved to a single system,
the "arabic" numbers. This is great for it stimulates trade and 
flow if information between cultures. 

Early on phone systems used different addressing schemas, some used names,
some used names and numbers, but over time all have evolved to use only 
numbers. This is great for interoperabilty and universal access, I can use a
phone in China even if I do not speak or read Chinese. 

Domain name system has similar characteristics as the telephone system it
allows
users to connect to any point on the earth. For that reason I think it is
perfectly reasonable to restrict the richness of expression in domain names as
universal access is as important if not more than nationalistic pride or
cultural 
preferences. 

We have choices such as
        limited but universal naming 
        rich but localized naming. 

Both can be supported, BUT we may end up with a system where two domain names
are needed, one from each choice. Thus if I want to use the domain 
"ÓGuð.com" as my main domain, but that may not be universally expressable.  
I may need to include on my billboards and business cards the domain name
"ogud202.com" which is universal.  "ogud202.com" may only be a DNAME to 
"ÓGuð.com" but that allows people that want to reach my site but do not
know how to or can not write Icelandic. 

>-James Seng
>
>"Oh, my URL is http://ZHONGGUO.GONGSI/ in China, but you should try to type it
>as http://GONGSI.ZHONGGUO/ when you are in Taiwan" :-)

Good example, this is a nightmare. 

        Olafur

--------
Olafur Gudmundsson - NAI Labs 			(443)-259-2389 
The Security Research Division of Network Associates, Inc.
ogud@tislabs.com  Olafur_Gudmundsson@nai.com  Private: ogud@acm.org