ICANN Announces Timeline for Development of a Project for the Technical Test of Inter

[idnowner]

In case you haven't seen this yet...

http://www.icann.org/announcements/announcement-14mar06.htm

[OldIDNer]

Thanks.

When they speak of "NS-records - permit the insertion (of) an internationalized label in the root zone without the duplication of a pre-existing sub domain structure"

Does this mean in effect, in this scenario, that .IDNs would be created separate from their .coms?

[bramiozo]

I think it means the exact opposite, there's no need to duplicate the existing structure for subdomains when inserting the internationalized label.
If you were right the "permit" wouldn't make sense :) .

[blastfromthepast]

Looks like they want to have the ability to do both. DNAMEing the existing ccTLD and gTLDs, and allowing for future deployment of top level IDNs. Testing for the ability to do .idn one thing, getting a new top level domain approved is another. While, DNAME, not being a new domain, wouldn't have to go through the same review process, right?

[OldIDNer]

So, both of these approaches (if used to the exclusion of the other say) allow for:

IDN.com <-> IDN.IDN ? (this seems to be the Dname solution)

The second approach seems to be a way to create new separate IDN tlds.

Appreciate any concise answers. I'm just trying to understand it in terms of what it means to the IDN.com speculator.

Thanks.

[sarcle]

This really sounds like what we have been saying all along.

They are going to use dname for the top levels of the idns that are already existing.

And they are allowing for future idns to be created. This was going to be done no matter what anyways.

I don't think there is anything bad in this. At least from how I read it. It doesn't once say on this that they are going to create an alternate .com idn. All they are doing is allowing for more extentions to be added in the future. You know icann they need to be able to have room for shitty exts. so they are able to mess up idn the same as latin.

[OldIDNer]

Yes, I agree, it's all good :). I'm happy just to have the IDN.com. Progress is being made.

I just wanted to understand the different approaches from a technical angle and what it meant if one were implemented over the other. Though of course they may both be implemented in some form (the .com IDN TLD dnamed, new .IDN TLD labeled).

I guess I'm just making sure that the Dname approach is the only way to make IDN.com <-> IDN.IDN work (at least of the two approaches being considered).

[sarcle]

Yes, I agree, it's all good :). I'm happy just to have the IDN.com. Progress is being made.

I just wanted to understand the different approaches from a technical angle and what it meant if one were implemented over the other. Though of course they may both be implemented in some form (the .com IDN dnamed, New .IDN tld labeled).

I guess I'm just making sure that the Dname approach is the only way to make IDN.com <-> IDN.IDN work (at least of the two approaches being considered).

Yes, Icann's lack of layman's terms is something they are probably proud of.

Sounds like both will be implemented in time. Of course it would be excellent if someone would send this memo to Verisign for reassuring.

As far as making idn.com and idn.idn the same or something different. They can't really test something that isn't on the market. IDN.com is the only thing that everyone has in all languages. It's taken them over 5 years to get to this point. Now imagine if they had to create an alternate .com in all languages and test it "en masse" by 3rd quarter this year. I don't see that happening. :)

[OldIDNer]

Exactly. I guess I just wanted to understand the second approach better, which to me reads as the creation of new tlds that would be separate from any other existing tld, and would mean if applied to ".com", a separate .com IDN TLD would be created, not connected to our IDN.com. But you are right, that would be tough as hell I imagine. Maybe they will go dname or will use both ways in some form like you suggest.

I did write someone from Verisign just to get it clear in terms of what this second approach means exactly.

In any case its great to see some action from ICANN. Thank you IE7 and China :)

[Clotho]

Ahh, Its a testbed. Where do you read that they would be interested in implementing both? Isn't the purpose of testing more than one solution so that you can choose the best one? There is nothing preventing them from implementing both if they so choose (barring the DOC). I just don't see where you read that into it.

[OldIDNer]

I think that is just a speculation being made.

[sarcle]

I think that is just a speculation being made.

Yes, we were just having a discussion of possible outcomes. It's surprising that no one else has entered the discussion on this thread as to most all other topics concerning dname and the possible ext. route are pertaining to this very subject.

[OldIDNer]

Yes, I was a little confused, as this second approach (going that way only) does seem to concern the creation of a unique IDN TLD that would not alias to our IDN.com (unless I'm wrong on that), in the case of a creation of an IDN.IDN (.com), if that would be done. It's possible I'm just misunderstanding it, I'm not very technical, hence my questions regading the matter, trying to get a grasp on the implications of both approaches.

[Explorer]

As far as I understand, Verisign is behind ICANN's decisions most of the time, so it looks like ICANN is showing the public they are open to several approaches and will be testing both. However, the DNAME solution is the preferred way of doing things. They just can't announce it RIGHT NOW. It is all PR/PC stuff at this point.

In a very remote case that DNAME will not happen (and I stress the word "remote"), we will still make out like bandits. DNAME is great to have, but not a must to have.

[OldIDNer]

Yes, I agree. We already have the IDN.com, and that ain't too shabby imo.

[Clotho]

As far as I understand it the NS solution is the creation of .IDN in the root. They would be separate from any existing .TLD or .CCTLD but there is nothing preventing Verisign from mapping existing .com into new .IDN (version of .com). IE. taking all the Chinese .com's and giving those owners the equivalent .IDN (in Chinese). This would be up to Verisign however. I'm just pointing out that they could do this if they wished to if the NS solution was chosen.

.com is a brand. It is the most powerful brand on the internet. .com has served ICANN well too in my opinion. Having a dominant internet brand has been as useful as having a single internet. (which is the purpose of ICANN, to preserve the root). Anything that fragments .com weakens it and I think the owner of any valuable brand would fight against that.

[OldIDNer]

As far as I understand it the NS solution is the creation of .IDN in the root. They would be separate from any existing .TLD or .CCTLD but there is nothing preventing Verisign from mapping existing .com into new .IDN (version of .com).

.com is a brand. It is the most powerful brand on the internet. .com has served ICANN well too in my opinion. Having a dominant internet brand has been as useful as having a single internet. (which is the purpose of ICANN, to preserve the root). Anything that fragments .com weakens it and I think the owner of any valuable brand would fight against that.

ok, I was wondering if this could work/be done in the case of NS solution

agree

thanks

[Drewbert]

>As far as I understand it the NS solution is the creation of .IDN in the root. They would >be separate from any existing .TLD or .CCTLD

Correct!* In final form, it'll just be like any other potential gTLD provider - they'll have to put up their hand and beg ICANN for inclusion. opefully they'll have rules like com/net but they may go bizarro like .pro/mobi etc.

>but there is nothing preventing Verisign from mapping existing .com into new .IDN
>(version of .com). IE. taking all the Chinese .com's and giving those owners the
>equivalent .IDN (in Chinese). This would be up to Verisign however. I'm just pointing
>out that they could do this if they wished to if the NS solution was chosen.

Incorrect!* Verisign may OPERATE the root servers, but they cannot just go bunging in DNAME mappings in there. ICANN/DOC have management rights. Verisign might want to suggest the mappings that it wants to provide for com/net/bz/tv etc, but ultimately ICANN/DOC gets to say which ones go in.

There will be multiple one-way .IDN -> .com mappings. I would be guessing that after the testbed phase (which I can't see any major technical problems arising) ICANN will ask GAC members what mappings they want, there will be a board vote and BLAMMO it's all there.

And let's not forget that it opens the way for all sort of mapping possibilities. .méxico -> .mx etc.

It appears they're going to actually have a live test on the root servers? That could be fun. A fake IDN gTLD and a DNAME mapping (interesting if they use something that might be considered in the final plan).

* Little Britain series 2 "Orchestral triangle player" for the BBC 3 viewers in our midst. :^)

[gammascalper]

>As far as I understand it the NS solution is the creation of .IDN in the root. They would >be separate from any existing .TLD or .CCTLD

Correct!* In final form, it'll just be like any other potential gTLD provider - they'll have to put up their hand and beg ICANN for inclusion. opefully they'll have rules like com/net but they may go bizarro like .pro/mobi etc.


So, implementation is easy, but roll-out and general acceptance may be a steeper slope to climb.

I *think* I can sleep a little better.

[Clotho]

> Incorrect!* Verisign may OPERATE the root servers, but they cannot just go bunging in DNAME mappings in there. ICANN/DOC have management rights. Verisign might want to suggest the mappings that it wants to provide for com/net/bz/tv etc, but ultimately ICANN/DOC gets to say which ones go in.

I wasn't suggesting that Verisign would apply their own DNAME mapping overtop of any NS solution if implemented. What I was suggesting is that they would be in a position to provide the owners of existing IDN.com names with names in the .IDN equivalent of .com

Say for example that the NS proposal is adopted and a new domain extension .コム is created in the root. (a form of .com in Japanese). Do you think with all the talk about trademarks at ICANN that anyone but Verisign would be allowed to operate such an extension? It would be Verisign's extension and under the NS proposal it would operate separately from IDN.com. Since Verisign operates this extension it would be within their power to provide all the existing owners of Japanese IDN.com with the same domains in IDN.コム. Why would they do this? To avoid confusion on a number of levels. If Japanese IDN.com doesn't resolve to the same site as IDN.コム the .com brand is diluted and users will lose faith in it. There is nothing that says that they have to do it but I believe it would be in their own best interests to do so.

Obviously when you explore the NS concept it quickly becomes a quagmire of confusing extensions and their relationship to existing ones. This would not be good for the Internet. Clarity and Consistency are required for the Internet to function as a useful tool.

[Explorer]

So, implementation is easy, but roll-out and general acceptance may be a steeper slope to climb.

I *think* I can sleep a little better.

What makes me sleep better is knowledge that with all different outcomes and possibilities, Verisign is in my corner. As sleezy and greedy as they are, it's great to be on the same side with them for a change. Maybe I could relax and wait for them to fight for my .coms..:-)

[Clotho]

What makes me sleep better is knowledge that with all different outcomes and possibilities, Verisign is in my corner. As sleezy and greedy as they are, it's great to be on the same side with them for a change. Maybe I could relax and wait for them to fight for my .coms..:-)

I won't know for certain that Verisign is in my corner until an IDN.IDN solution is established and I am happy with the outcome. The only people with something to gain from the NS proposal are the registrars that would be able to charge people yet again for more names. The fact that Verisign is a registrar and was also the ones to propose DNAME is a positive thing. It tells me that they understand the absolute necessity of keeping their brand consistent. Being able to charge money for more extensions may appear desirable from the registrars’ point of view in the short term, but it would prove disastrous if people lost faith in the brand and stopped using it due to confusion in the long run.

[Explorer]

I won't know for certain that Verisign is in my corner until an IDN.IDN solution is established and I am happy with the outcome. The only people with something to gain from the NS proposal are the registrars that would be able to charge people yet again for more names. The fact that Verisign is a registrar and was also the ones to propose DNAME is a positive thing. It tells me that they understand the absolute necessity of keeping their brand consistent. Being able to charge money for more extensions may appear desirable from the registrars’ point of view in the short term, but it would prove disastrous if people lost faith in the brand and stopped using it due to confusion in the long run.

Trust me, Verisign is in your corner. They will be jumping up and down like the rest of us when DNAME will get implemented and will be pushing and lobbying for it.

DNAME gets implemented - IDN.IDN will become IDN.com. IDN.com will be paying a $6 or so to Verisign per year.

Another words - for every IDN.IDN registered anywhere, Verisign will get $6 or so a year.

This, of course, applies only to .coms and .nets.

Who do you think came up with the DNAME solution in the first place and why? :-)

[sarcle]

Trust me, Verisign is in your corner. They will be jumping up and down like the rest of us when DNAME will get implemented and will be pushing and lobbying for it.

DNAME gets implemented - IDN.IDN will become IDN.com. IDN.com will be paying a $6 or so to Verisign per year.

Another words - for every IDN.IDN registered anywhere, Verisign will get $6 or so a year.

This, of course, applies only to .coms and .nets.

Who do you think came up with the DNAME solution in the first place and why? :-)

This is correct! No matter what, Verisign is not going to screw themselves.

Maybe I'll just go join the group that is crying over the possibility of $12 .com in the next few years. Oh wait a second no I won't. I'm going to be flippin' rich!

[Clotho]

This is correct! No matter what, Verisign is not going to screw themselves.

Maybe I'll just go join the group that is crying over the possibility of $12 .com in the next few years. Oh wait a second no I won't. I'm going to be flippin' rich!

If I understand everything correctly DNAME does seem to be the best solution for the Internet as a whole.

It doesn't change anything in the root servers. (Desirable from a technical point of view.) I hope I understand this correctly or at least it isn't as invasive as NS.

It preserves the integrity of existing .TLD brands. (Desirable from an end users point of view and by the owners of said brands.)

I do think that it is good that ICANN are looking at more than one solution. It is their mandate to be objective and determine what is best for the Internet as a whole. If they just implemented DNAME without any other consideration certain interests would be obliged to call foul and rightly so. This would only impede any solutions implementation.

[Drewbert]

> Incorrect!* Verisign may OPERATE the root servers, but they cannot just go bunging in DNAME mappings in there. ICANN/DOC have management rights. Verisign might want to suggest the mappings that it wants to provide for com/net/bz/tv etc, but ultimately ICANN/DOC gets to say which ones go in.

I wasn't suggesting that Verisign would apply their own DNAME mapping overtop of any NS solution if implemented.

You implied that if DNAME was implemented Verisign could choose whatever mappings they wanted. Patently incorrect.

What I was suggesting is that they would be in a position to provide the owners of existing IDN.com names with names in the .IDN equivalent of .com

IF they get awarded an IDN .gTLD.

Say for example that the NS proposal is adopted and a new domain extension .コム is created in the root. (a form of .com in Japanese). Do you think with all the talk about trademarks at ICANN that anyone but Verisign would be allowed to operate such an extension? It would be Verisign's extension and under the NS proposal it would operate separately from IDN.com.

Rubbish. .com extension is the property of the USG via Doc. Verisign MANAGES .com by contract. They have ZERO TM rights.

I say again if DNAME is approved, ICANN/DOC decide the mappings, not Verisign.

If a seperate IDN gTLD is approved and Verisign gets management rights, I don't think EVEN THEN they can do mapping to .com from it without approval from ICANN.

Since Verisign operates this extension it would be within their power to provide all the existing owners of Japanese IDN.com with the same domains in IDN.コム.

Well they could psuedo map it by assigning registrations of the .IDNgTLD names to the owner of the corresponding .com, but where's the beef for them if they do that? Running 2 TLD registries and making the same amount as they were with 1? Yeah, THAT's going to go down well with the stockholders.

If Verisign won management rights to a new IDNgTLD and wanted to map it to .com, I think they'd offer .com and .net holders the first come first served rights to the same 2LD in that gTLD but it wouldn't be for free!

Why would they do this? To avoid confusion on a number of levels. If Japanese IDN.com doesn't resolve to the same site as IDN.コム the .com brand is diluted and users will lose faith in it. There is nothing that says that they have to do it but I believe it would be in their own best interests to do so.

Still too messy. Verisign will lobby for DNAME for com/net because it's simply a small technical upgrade to the root servers and it's done and their potential customer base explodes overnight.

New IDNgTLD's will probably be like .mobi, .pro. etc - boutique with little demand. The big deals will be DNAMED com/net and DNAMED ccTLD's.

>I do think that it is good that ICANN are looking at more than one solution. It is their
>mandate to be objective and determine what is best for the Internet as a whole

They are solutions to 2 different problems.

1. The ability to access existing interent content without having to use latin characters to get to it. - DNAME cures this problem.

2. The ability to define new TLD's without having to use latin characters to do so - punycode in the root zone cures this problem.

One isn't better than the other overall. Both have their uses. I can see no technical reason why both can't be chosen, either at the same time, or on different time scales.

[OldIDNer]

well, will be interesting to watch

[hanidn]

well, will be interesting to watch


In April, ICANN will release a project description for the technical test. For the month of April, the test plan will be open for public consultation.
In May, the committee will amend the plan in response to relevant replies from the public and submit the project to the ICANN board for approval.
The board is expected to give its approval for the project no later than the ICANN meeting in Marrakesh in late June.
The IDN implementation test is expected to launch in July 2006.