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

From: [email-masked]
Date: Tue, 16 Oct 2001 16:49:13 -0700

Hi, John:
  I have redescribed all the models  
somewhat graphicly as following.  If this does 
not lineup clearly, please let me know.

 Raw input         ?IDN?                 output

DNS Model:
1) Key Stroke   --> Input Processing --> DNS

IDN Model:
   Vioce       |
2) URI line    |--> Input Processing --> DNS
   Input beffer|

John's Driectory Model:

   Vioce       |
3) URI line    |    layer1: [nameprep]   --> DNS
   Input beffer|
                \   layer2: TC/SC 
                 \  layer3: GB/BIG5
                  \         Yellow pages
                   \---^

CJK arguing for:

   Vioce       |[nameprep??]
4) URI line    |-->      layer1:          --> DNS
   Input beffer|
                \-->     layer2: TC/SC 
                 \->     layer3: GB/BIG5
                                 Yellow pages

Idn-map Proposed Model:                  

   Vioce       |[idnmap]
5) URI line    |-->     layer1:          --> DNS
   Input beffer|-->           TC/SC
                \-->          GB/BIG5
                 \     
                  \     Layer2: Yellow Page
                   \    Layer3: User error check   
                    \---^
  
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

On Sat, 13 Oct 2001 15:11:41 -0400 John C Klensin <[email-masked]>
writes:
> Dear L.M.Tseng,
> 
> I think I didn't answer this message (ill-formed RFC 2231
> headers tend to route mail into a low-priority folder).  My
> apologies.
> 
> Comments in line below...
> 
> --On Thursday, 30 August, 2001 12:09 +0800
> "=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?="
> <[email-masked]> wrote:
> 
> > Hi !  Klensin:
> >            May  I  ask a question related in
> > draft-klensin-dns-search-01.txt ?
> > 2. A three (or four) search-layer environment.
> > (1) The DNS, with the existing lookup mechanisms
> > (2) A restricted, facet-based, search system.
> > (3) Commercial, localized, and potentially topic-specific,
> > search    environments.
> > (4) Something else?
> > 
> >           The current existed and used Letter-Digit-Hyphen DNS
> > server is the Layer1 mechanism. Now ,what is the layer of
> > nameprep + IDNA  ?
> 
> Since it is intended to go into the DNS, it is part of sublayer
> 1.  Or it is unnecessary, being superceded by better facilities
> at sublayer 2.
> 
> >  Actually, the native coded multilingual
> > domain name  will be treated by AP and passed to nameprep
> > module and transfomed to ACE name, the ACE name will be feed to
> > resolver of LDH-DNS , so it is backward compatible to pure
> > ASCII  domain name.
> 
> >            The input of resolver module is the interface of
> > Layer2 and Layer1   ?
> 
> I think I haven't effectively communicated what is going on
> here.    Think about it this way:
> 
> Sublayer 3 provides two kinds of services: localization and
> anything associated with it and any specialized "yellow pages"
> services that may be appropriate to a given area.  While I would
> expect that we would ultimately define some sample templates and
> protocols, it is not assumed to be a homogeneous Internet-wide
> service.
> 
> Sublayer 2 provides language-based services, and is sensitive to
> a range of social/political issues.  I would expect TC <-> SC
> mappings and country-specific case mappings --all of the things
> that can't be done in Nameprep without heuristics to determine
> what is intended, such as avoiding conversion of Kanji to SC,
> French versus Canadian case mapping differences, national and
> line of business trademark distinctions, etc-- to occur at
> sublayer 2.  And, because this layer is _not_ the DNS, the
> various nasty problems involving lengths, need to use
> uncomfortable encodings for backward compatibility purposes,
> etc., are just not relevant (or can be reconsidered with fewer/
> different constraints).
> 
> Layer 1 is the DNS.  Whether or not IDN capability is needed
> there (IDNA/ACE or otherwise) is an open question, but, if IDN
> facilities do appear there, they can, and should, be strictly
> character-based.  I.e., no special considerations for particular
> languages, different rules for different scripts, etc.
> 
> If you read that description from the bottom up, you get the
> motivation for doing this.  At sublayer 1 (the DNS) there is
> considerable demand for capabilities that are difficult or
> impossible to do correctly and consistently at that level,
> including all of the language-related issues.  So we push those
> issues up a level and use a different set of mechanisms.
> Similarly, there is considerable demand for localization to
> accomodate local or national needs, but, if localization occurs
> at a sufficiently low level, it is a threat to overall
> connectivity and interoperation of the Internet.  So we push
> that yet another sublayer higher, so that it can be separated
> from, e.g., language functions that are still international in
> scope (e.g., Chinese is spoken in countries all over the world.
> Even though it is not be the majority language in many of them,
> it remains important.)
> 
> >> > If you can come up with a proposal that describes what to do
> >> > about ALL the Han characters in Unicode, I will be very
> >> > happy to hear it.
> 
> >> And, unless whatever is done is isolated -- through
> >> procedures, structure, or layering-- in a way that is robust,
> >> accessible to
> >           I think the procedures, stucture, or layering is the
> > module above layer1 ?
> > But it must be between name-input of AP and Layer 1 input
> > interface . My question is
> > what is the relation betwwen IDNA , Layer 3 , Layaer 2 ,
> > nameprep and  Layer 1 ?
> 
> I hope the above comments explain this; I will try to clarify it
> further in the next revision of the internet draft.
> 
> > Does IDNA and nameprep are in the layer of  Layer 2 ?  How a
> > restrict facet search system  communicate with Layer1 thru
> > which module ?
> 
> The contents of the "directory" that is searched by such a
> system contains DNS names.  I.e., additional information exists
> at each sublayer, with more information (language, country,
> etc., in those facets) at sublayer 2 than exists at sublayer 1
> (the DNS), where only a string appears at the DNS sublayer.
> Now, the DNS name that appears in sublayer 2 can be _any_ name
> deemed valid in  the DNS.  If we make IDN names valid there
> --via IDNA/ACE processing or otherwise-- it can contain those
> names.  But it need not do so: in principle, one could have an
> entry of 
> 
> 	{ layer-2-name (proabably an unrestricted,
> 	Unicode-valid, string for the relevant language); TC;
> 	Taiwan; ...} 
> 
> pointing to a FQDN most of whose labels were generated names,
> i.e., essentially gibberish that conformed to the ASCII LDH
> rules.  Whether or not that was desirable would depend on
> whether you need mneumonic value in sublayer 1 (DNS) names.  If
> you do, then it would make sense to put IDN names in the DNS,
> and to push the output of sublayer 2 through stringprep, etc.
> If not, one could avoid that small marginal overhead.
> 
> Similarly, sublayer 3 could, if desired, be used to map between
> names in, e.g., Big5, and Unicode names on a _name_ basis,
> resolving any ambiguities that might appear in a pure
> character-by-character remapping of the two (conceptually
> slightly different because of compromises made in Unicode)
> character coding methods.
> 
> >     Does there are a defined port or module interface to let
> > the isolated function module can be link to cooperation ?
> 
> I don't adequately understand this question.  But the purpose of
> thinking about this multilayer approach is reexamine
> requirements and expectations.  For those that require features
> that are incompatible with the design of the DNS, such as
> dependencies on the word-formation or grammatical rules of
> particular languages, the idea is to provide a reasonable way to
> accomodate those features without trying to "trick" the DNS into
> supporting them.
> 
> I hope that helps clarify what is intended.  If you have
> additional questions, I will try to respond to them much more
> quickly.
> 
> regards,
>     john
>

---

From: "Kenny Huang" <[email-masked]>
Date: Wed, 17 Oct 2001 09:27:40 +0800

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.

Kenny Huang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, October 17, 2001 7:49 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: [idn] Re: A Search-based access model & SC/TC conversion
>

---

From: "Soobok Lee" <[email-masked]>
Date: Wed, 17 Oct 2001 11:19:23 +0900

----- Original Message ----- 
From: "Kenny Huang" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 17, 2001 10:27 AM
Subject: RE: [idn] Re: A Search-based access model & SC/TC conversion

> 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