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

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



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?

-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" :-)

Olafur Gudmundsson wrote:
> >1. localization needs. for example, some queries raised on the issues of
> >   doing <COUNTRY>.<2LD>.<DOMAIN>.<HOST> in the reverse way. Make more sense
> >   for some languages and country convention.
> >   (Oh boy, this is going to get flame!)
> 
> No need to flame.
> Presentation issue: DNS expresses domain names on the wire in the
> least significant to most significant order. Any application can accept and
> display labels in different order or show only some of the labels.
> Suggesting changing significance of label order is dead on arrival in
> the context of DNS.
> 
> >
> >
> >2. localization needs again. Does double-width period counted as a domain
> >   delimitator like a single-width period? On a similar notes, this is
> >   related to double-width Alphanumeric vs single-width alphanumeric.
> 
> DNS presentation issue again: Domain names on the wire are represented as
> <length><string><length><string><0>
> where length is 1..63
> where string is [USASCII] or BINARY depending on who you talk to.
> 
> Each language/implementation CAN make up it's own rules about separators.
> Historically "." has been the separator of labels in domain names.
> Using the same separator everywhere is a real good idea but that will not
> stop people from creating new separators.
> 
> >
> >
> >3. localization need once more. How to handle right->left writing order
> >   such as Arabic. One consideration is treat this as an non-issue because,
> >   for example, MS Windows CP1256 which defines Arabic actually encodes
> >   the domain name in the correct byte order as per norm from left->right
> >   but the render reverse it. On the other hand, this may not apply on
> >   some other system such as Mac or Unix.
> 
> This is a real good question: we do not want to create a system where there
> are two possible orders, the language aware and the language ignorant
> implementation come up with different names.
> The my gut feeling is force wire format to be left to right in all cases,
> but I'm willing to listen to arguments for and against this.
> 
> How this is done in different operating systems is not relevant to this
> discussion.
> 
>         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