Standards and localization (was Dot-mapping)

YAO Jiankang yaojk at
Sat Dec 8 05:06:20 CET 2007

----- Original Message ----- 
From: "John C Klensin" <klensin at>
To: "Yangwoo Ko" <newcat at>
Cc: <idna-update at>; <fujiwara at>
Sent: Saturday, December 08, 2007 8:21 AM
Subject: Re: Standards and localization (was Dot-mapping)

> --On Saturday, 08 December, 2007 05:33 +0900 Yangwoo Ko
> <newcat at> wrote:

>> (2) Even in a very clear local context, there can exist
>> multiple (and hence incompatible) practices. (I think we have
>> many examples for this.) In such a situation, it may take
>> quite long time to converge on a consensus and user
>> experiences are not that good.
> Yes.
> But I think everyone is missing something in this discussion,
> something that I didn't start to realize until a few days ago.
> The idea of mapping dots is a fundamental bug in the IDNA spec.

I  do not think that it is a bug. it is the result of IDN WG discussion.

> It violates the fundamental principle of IDNA, i.e., that IDNs,
> in ACE form, work transparently with legacy DNS servers,
> resolvers, cachesl, tunnels, etc.  

IMO, It follows the principle of  IDNA.

> Suppose a DNS processor or interface that is not IDNA-aware
> encounters one of the three "recognize as dot" characters
> specified in Section 3.1 of RFC 3490 (U+3002 (ideographic full
> stop), U+FF0E (fullwidth full stop), U+FF61 (halfwidth
> ideographic full stop). 

The domain name with the dot of (ideographic full
 stop), U+FF0E (fullwidth full stop), or U+FF61 (halfwidth
 ideographic full stop) is IDN even all the lables of this domain name are ASCII characters.

So in this situation, IDNA is needed to deal with this domain name first.

> Because that legacy processor is, by
> definition, not IDNA-aware or IDNA-conformant, it sees that
> characters as one or more ordinary octets with undefined
> semantics.   (See RFC 2181 for a discussion of this and note
> that the DNS does not enforce the LDH rule.) Certainly it cannot
> map them into U+002E (full stop) or recognize them as equivalent
> to U+002E because it doesn't know anything about IDNA.    

true.  non IDNA-aware software encounters IDN can not deal with IDN properly as IDNA RFC3490 said.

> Without that mapping, the string cannot be parsed into labels
> since conventional (legacy) FQDN parsers separate labels _only_
> on ASCII period, 0x2E, aka U+002E.

true. non IDNA-aware software  can  not parse  IDN.

> Not being able to parse the string into labels would result in
> rather serious lookup failures,  but the problem is even worse
> because:

if I understand it correctly,
it seems that you have the following assumption:
The domain name with the dot of (ideographic full
 stop), U+FF0E (fullwidth full stop), or U+FF61 (halfwidth
 ideographic full stop) is not IDN. so this domain will be sent to DNS lookup server without IDNA process.
actually, according to RFC3490, it is IDN.
Since it is IDN, it must be dealt with IDNA before being sent to DNS lookup.
if that happens, there have not the problem as you said.

YAO Jiankang

More information about the Idna-update mailing list