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

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

--On Tuesday, 04 December, 2001 09:48 +0800
"=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?="
<tsenglm@cc.ncu.edu.tw> wrote:

>...
> In this mailing list there are many suggestions , but these 3
> requirements are come from a fact , CJK characters are not
> completely unified, there are a lot of variants with the same
> meaning and pronouncing. All the requirements can not be solved
> by this IDN sublayer.

I think most of us understand this.

> 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?

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.

> 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?

Sorry for my ignorance here, but my sense is that we are just not
communicating very well about this key issue.

    john