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

[John C Klensin <klensin@jck.com>]

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?="
<tsenglm@cc.ncu.edu.tw> 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