PDA

View Full Version : Mapping/Aliasing


Rubber Duck
15th February 2008, 08:04 AM
https://delhi.icann.org/files/Delhi-WS-gTLDEnvironment-14FEB08.txt

ERIC BRUNNER-WILLIAMS: Eric Brunner-Williams from core.
Ram, in the 2001/2002 time frame in the Chinese domain name consortium context, we were then grappling with not variations that looked alike but with variations that did not look like alike but which had identical meaning. This is the simplified Chinese/traditional Chinese table debate issue or whatever.
But the enduring thing that we have from there is the notion of equivalence classes across scripts on a per-character basis, and here we're not looking not so much per-character issues but string issues, we have the possibility of looking at that as a concatenation of equivalent characters or recognizing that if the -- even if the -- a set of characters are not character-by-character equivalent as they were in the SC/TC context, that the semantic -- the intended meaning of the string or the apparent meaning of the string, as in the four examples, Hindi, Urdu, Arabic and English, that these could define an equivalence class.
With that concept in mind, knowing what we were trying to do in SC/TC -- that is, cause a registration for one label to be equivalent to the variants of that label so that the label effectively was a -- appeared in one namespace multiple times for each one of the variants, with all resolving to the same A record, and more interestingly, the two Chinese registries that were cooperating, or at least hypothetically cooperating, the TC -- the CN registry and the TW registry, doing cross-registration of the variants automatically, so that a registration of one variant in one registry automatically caused the A record to resolve in the other registry for either variant in the other registry.
So we have the possibility of looking at equivalence classes, the experience that we have from the CDNC period, and looking at IDNs as a possible -- looking at equivalence classes as a way that we can say that these multiple strings actually result in a single zone file, or they result in multiple zone files. Or the identical entries in a single unified zone file or identical entries in multiple discrete zone files.
So this is a technique that we haven't really explored or talked about. It's kind of been an assumption of some people who are somewhat business minded that each possible variant represents a new business opportunity for ICANN as a revenue collector, or for some business as a gTLD operator.
And this isn't necessarily the case. That's the point about equivalence classes, that we might be looking at proposals that involve folding much of this onto one zone or fewer than the maximum possible number of zones for the maximum possible number of scripts.

clipper
15th February 2008, 08:15 AM
...It's kind of been an assumption of some people who are somewhat business minded that each possible variant represents a new business opportunity for ICANN as a revenue collector, or for some business as a gTLD operator.
And this isn't necessarily the case. That's the point about equivalence classes, that we might be looking at proposals that involve folding much of this onto one zone or fewer than the maximum possible number of zones for the maximum possible number of scripts.

This guy is spot on, but...

The assumption that ICANN is anything but business minded let alone "somewhat business minded" is absurd, at least as an American businessman.

If I ran ICANN, I'd want as many "zones," as many scripts, and as many ccTLDs and gTLDs as I could approve, and I'd do it last year if possible.

But I'd be sure to roll them out strategically, one at a time to get as many domainers and new NICs as I possibly could, and possibly spread it out over a course of years. Leaving, of course, the mapping of existing gTLDs for last.

JMHO.

Rubber Duck
15th February 2008, 08:43 AM
That may indeed be an American perspective, but what is important from a commercial standpoint is the total number of registrations not the total number of extension that may be registered. From Verisign's perspective it is important not only to maximise the total number of registrations, but also to maximise their share. By diluting their dot com brand in the way you suggest would actually run totally counter to achieving that goal. They need the biggest cake, and they need the maximum share of the cake. The number of slices it is actually cut into is totally meaningless. The more it is sliced up, the more of the cake that is going to lost to others attending the party.

This guy is spot on, but...

The assumption that ICANN is anything but business minded let alone "somewhat business minded" is absurd, at least as an American businessman.

If I ran ICANN, I'd want as many "zones," as many scripts, and as many ccTLDs and gTLDs as I could approve, and I'd do it last year if possible.

But I'd be sure to roll them out strategically, one at a time to get as many domainers and new NICs as I possibly could, and possibly spread it out over a course of years. Leaving, of course, the mapping of existing gTLDs for last.

JMHO.

phio
15th February 2008, 08:43 AM
This is very interesting news. Not sure I agree clipper 100% as the multiplication to the powers of 10 and on and on of domain and extension combos is probably not what ICANN will be into with the release of IDN.IDN. I think they already have their hands full and will probably be looking at the best solution for simplifying the process of the roll-out (which of course will come in phases) Aliasing to the existing .com and .net versions would be great for us here, especially for those who got in early (I didn't). I would definately prefer an offer of purchasing the alternate (native) extension, rather than spending more time waiting for sunrises and sunsets, usless of course we're talkin tequila sunrises. This has been discussed here before, but what's new is what was RD brings us via dehli...