I believe in a more strip down generic framework on handling of IDNs and its
variants (e.g. registration, deletion, transfer, etc). But the exact
algorithm to generate the variants should be defined per language.
Total agreement. This is why language working groups and cross-zone
Managers are necessary (every "cn" zones across all the TLDs). The ML TLD
solution can only lie with such "TLD-language sub-TLD" whatever the way
this may be implemented if we want to styay consistent with RFCs 920, 1591,
3066, etc. Obviously the ACE system and the specific choice of "xn--" add
complex operational; political and legal problems.
I note that the work achieved by the OPES working group might provide a
possible solution in having an OPES on the path as a proxy to the resolver?
The OPES could easily transcode punycode and MLTLD from tables language
TLD listed as ".com-mus" for ".comCreek" IDNs into a "xx--mus.com". I feel
that such a task would be directly in line with IAB requirements to OPES
and the way WG-OPES wants to support an enlarged set of protocol. The
call-out protocol under final drafting could permit an OPES Processor
acting as a pre-resolver to use very simple language oriented distatch
rules and to appropriately respond in every language.
Dispatch rule from Creek to DNS ".com-mus" (or "comCreek") --> transform in
"x--xmus.com"
Dispatch rule from "x--xmus.com" to "comCreek".
OPES could process the variant aspect (I would think better named
[psuedo]synonyms).
One of the interesting feature would be to permit language alliances for
similarities and IP reasons.
jfc