[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] Re: A Search-based access model & SC/TC conversion
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 <klensin@jck.com>
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?="
> <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
>