RE: Layer 2 and "idn identities" (was: Re: [idn] what are the IDN identifiers?)

["???" <tsenglm@cc.ncu.edu.tw>]

Dear  John:
                        To do right thing is never too later.  I must
thanks  you give me the chance to explain it.
        I have asked a question about the nameprep belong to which layer
on your  multi-layer DNS searching architecture.  I do not get a clear
answer.  Traditional LDH DNS is server based approach,  current IDN use
client side ACE encoding before  
passing the query to resolver,  it is an additional sublayer above
traditional DNS system.  Now, the burden and function of DNS server for
IDN is not so different , even there are  TC/SC IDN comparison as the
same in DNS server. We do not expect DNS can do any thing. 
> -----Original Message-----
> From: John C Klensin [mailto:klensin@jck.com] 
> --On Tuesday, 04 December, 2001 09:48 +0800 
> <tsenglm@cc.ncu.edu.tw> wrote:
> > But if there are no basic mechanism or
> > scheme in the core sublayer , the upper layer work will not be 
> > happened and compatible.
> 
> This is the statement that I, at least, still don't 
> understand. Why is it not possible to 
> 
> 	* register a DNS name, in, e.g., IDNA-ized SC, and then 
> 	
> 	* do the TC-SC mappings, and resolution of ambiguous
> 	cases as needed, in an upper sublayer?
> 
          It is possible ! Just like you can use a screen based Han
character translator such as NJStar to do transliteral conversion to
another CJK characters.  You can solved the language communication
problems in this way.  But this approach can not solve the basic
requirements (let me copy them back).
----  What  are solved ?
----       The  IDN sublayer can/need  not solve the language
translation problem. 
----Users need an IDN to satisfy:
----        (a) can communicate with TC/SC  hostname
----        (b) to reduce the 2^N records in registration. 
----Administrator need an IDN to satisfy:
----        (c) to avoid the un-predictable resolving of  hostname in
delegated DNS

         Except you assume all the TC/SC IDN are collected in one DNS
registry and no delegation of  sub-domain name. you can not avoid the
requirements of (b) and (c).

> Put differently, if we agree that the whole TC-SC matching 
> requirement cannot be satisfied at the DNS sublayer, why is 
> doing _some_ TC-SC mapping necessary at that sublayer?  Doing 
> it all in one place, at the sublayer at which all of the 
> issues can be addressed, would seem to me to have some 
> elegance about it and be much better from a modularity standpoint.
>
         Right !  Why not an integrated module ? That is so beautiful !
I think you will not try to use window word to do any simple input for a
small character string. We have suggested to use an external
modified-LDH-DNS server cooperated with IDNA ACE to help to solve the
"openness" of  Chinese characters and  (a),(b),(c) requirements.  But it
need the supporting of  IDNA and nameprep sublayer to do it.  Someone
have suggest to use CNRP to do server approach , but it is all outside
of IDNA and nameprep supporting .  So the problems of (b) and (c) come
back again.
         Why doing_some_TC-SC mapping at that sublayer ?  
The question is basically come from why CJK using a lot of characters
table  and try to insert to here ?  To solve (c) and to reduce the
troubles of (b) , we can not select doing_all_TC-SC mapping at here. To
do ALL must based on language approach that can not solve (b) and (c),
and from the logical definition , it is impossible to do ALL in an
character set with openness properties.
         If you want to find the original source of  Simplified Chinese
Characters of  PRC ,  then the draft provide it ,  the major SC of PRC
is based on that referenced document. It is "all" the source of  PRC's
SC. It is a very small set, but these character pair  are related to all
CJK area, so it is a global issue and it MUST be cooperated in here to
avoid the problems of requirement (c) and partial of (b) and (a). 
         Some people will ask why doing TC/SC in here ? It is a special
offer !  No ! We are forced to solve the requirements of (b) and (c)  to
save us.  TC/SC is not a CASE problem of uppercase/lowercase of ASCII ,
but we just using the property of comparison as the same with
case-insensitive and the individual chinese character always have
meaning associated to it . It is transliteral not a language
translation.  The mapping burden is client not the DNS server.  We  do
not need to rely
the LDH-DNS server to solve our TC/SC problems.
         Many people will not understand why do TC/SC mapping here and
not so happy  , when I ask back why all non-ASCII coded alphabet will be
mapped to ASCII in nameprep ?  Especially  those FULL-WIDTH alphabet
form in native code, such as JIS, GB...  character set.  I must
point-out  these full width alphabet characters never used in LDH-DNS
server , it is not a backup compatible issue.
         We recognize it is necessary to do it , but we also hope TC/SC
problems of requirement (b) and (c) can be understand. 
> > The most basic core element is the
> > validation module that will validate the CJK TC/SC mixed 
> hostname can 
> > be further treated by ACE encoder or not.
> 
> But, again, why do it there at all?   Why not just make rules,
> presumably per-registry, about the preferred form for 
> registrations (so as to avoid large numbers of "equivalent"
> registrations) and then solve the mapping/ matching problems 
> at a different sublayer?
> 
                If all people follow the rule of traffic ,  then the
traffic policeman and related organization is not need !
Reversely, policeman can not forced people to follow the rule , but it
can reduce the troubles. It is a mechanism of  layered architecture.
Especially when CJK area all follow the suggestion to do SC/TC in local
module that is outside of IDNA and work independently, then the problem
of (a) (b) (c) come back if there are hostname can be conversion freely.
               The same question can be applied to all nameprep parts.
               At least, Validation can lead delegation DNS to respect
the rule of registration and let CJK area can do advanced name service
based on a common base.  After someday , when people all follow the same
habits then nameprep part can be all removed.


Best regards

L.M.Tseng