Re: [idn] Re: A Search-based access model & SC/TC conversion

["Soobok Lee" <lsb@postel.co.kr>]

----- Original Message ----- 
From: "Kenny Huang" <huangk@alum.sinica.edu>
To: <liana.ydisg@juno.com>; <klensin@jck.com>
Cc: <tsenglm@cc.ncu.edu.tw>; <harald@alvestrand.no>; <James@Seng.cc>; <idn@ops.ietf.org>; <dhc@dcrocker.net>
Sent: Wednesday, October 17, 2001 10:27 AM
Subject: RE: [idn] Re: A Search-based access model & SC/TC conversion


> If IDN only take care internationalization issue, what is the mechanism to integrate
> localization (TS/TC, JPCHAR..,etc) into the framework ?  If there is no clear interface
> in IDN structure, the yellow search model would be the only way out.
> 
I agree.   
Without a certain "mandatory & clear" interface between IDN and the DNS search 
facility,  some applications would bypass this search layer and  run without any
TC/SC, jpchar, hangeulchar filtering. That is, they may make a direct  function call
into  "gethostbyname(ACE("ML.com")) without any interaction with the
DNS search agent for resolving potential ambiguities.

the mandatory search-based access model  may not be applicable to
non-interative applications like  email clients. Most email composing interfaces
do  not provide  interactive hostname-part validator for  recipients' email addresses.

It is very clear that the i18n mailbox-parts in IDN email addresses 
will inherit  all the issues of ambiguities of IDN hostname-parts.
the existences/details of hostnames can verified publicly, but the mailbox names
are often kept privately and therefore  we cannot apply public yellow/white page
search model on them.

Careful registration procedures are required  for both of IDN hostnames and IDN mailbox
names, because we cannot completely eliminate ambiguities from IDN through
mechinical processes like NAMEPREP. 
To minimize such global management overheads of IDN deployments, 
we should do our best to make nameprep/ACE  as perfect and general and efficient as possible,  within  time and resources  given to us.


Soobok Lee

> Kenny Huang
> 
> > -----Original Message-----
> > From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On Behalf Of
> > liana.ydisg@juno.com
> > Sent: Wednesday, October 17, 2001 7:49 AM
> > To: klensin@jck.com
> > Cc: tsenglm@cc.ncu.edu.tw; harald@alvestrand.no; James@Seng.cc;
> > huangk@alum.sinica.edu; idn@ops.ietf.org; dhc@dcrocker.net
> > Subject: [idn] Re: A Search-based access model & SC/TC conversion
> > 
> > The basic difference between 3) and 4,5) is where
> > the symbol table is used. In 3) the symbol table is 
> > UCS plane 0, from 0020 to d7af, about 56,000 symbols.
> > 
> > How to use the 56,000 symbol table is the difference
> > between 3) and 4,5). In 3) the process uses 
> > 
> > Local GB coded Yellow page search??
> >    |
> >    v
> > GB/BIG5 to Unicode conversion  
> >    |
> >    v
> > Unicode: TC/SC conversion
> >    |
> >    v
> > Unicode to ACE conversion for DNS
> > 
> > Am I correct in describing your model? 
> > 
> > Liana
> > 
> 
>