IDN Forums - Internationalized Domain Names - Verisign response on DNAME or the other implementation.

IDN Forums - Internationalized Domain Names (http://www.idnforums.com/forums/)

- General Discussion (http://www.idnforums.com/forums/general-discussion/)

- - Verisign response on DNAME or the other implementation. (http://www.idnforums.com/forums/5023-verisign-response-on-dname-or-the-other-implementation.html)

Verisign response on DNAME or the other implementation.

Quote:

Question:

People are talking about idn.idn, would Verisign see this implemented within the year?

Reply:

Yes I am very aware of all of the discussion surrounding idn.idn especially since the ICANN meeting in Morocco. One of the things which came out from that is that there is alot more work to do in this regard and as you know there are two approaches to addressing this. The implications are quite broad and while it might be fairly straightforward for a regional ccTLD it becomes much more complex in gTLDs.

Updates to the Core infrastructure for dotNet and dotCom typically have a 8-9 month development cycle and I can tell you that the next release does not have any work being done in the Core to support this. My guess is that there would have to be first some form of test bed and then approval from ICANN before we could even consider launching/offering a service and which technical approach is to be adopted.

More questions:

Stage 1. So ICANN needs to first plan for the "test bed". Any guess when that will be done? Let's assuming it is done by end of the year.

Stage 2. And after the "test bed" has been planned, it takes 8-9 month development cycle to roll out the test bed. Let's assume this would be done by end of 2007.

Stage 3. And how long will the "test bed" run? How long did the punycode testbed run? If we assume 9 months, this means the test bed will end mid-2008.

Stage 4. After the "test bed" ends, when will the live implementation be made? If it is done immediately (here we assume that there's no more another 8-9 month development cycle), and the assumption for 1, 2 and 3 holds, that means idn.idn will be live by mid-2008, roughly 2 years from now.

Note: Above timeline is just my assumption so that we can work out a hypothetical live implementation date. Anyone who has a different idea, please state out your assumptions for stage 1, 2, 3, and 4, be it 1 year or 1 month for each stage - please do not just say "I say it will be live by xx-xx-xx! I'm betting on it and my gut feel is always right!".

Re: Verisign response on DNAME or the other implementation.

I thought ICANN were doing the test bed "as we speak"?

But yes, given all we know about combined slowness of ICANN, IANA, VeriSign, Msoft, we should all be prepared for IDN.IDN to be a "long-haul journey", similar to IDN.com.

Thinking about it more and more, I am quite happy if IDN.IDN is delayed indefinitely, because I am sitting on a big pile of IDN.com names that are already attracting decent traffic. I want Thais to adopt IDN.com as their standard domain. Any "imminent release" of IDN.IDN is just going to cause confusion and stop companies from adopting IDN.com.

So long live IDN.com !!

Re: Verisign response on DNAME or the other implementation.

Quote:

Originally Posted by domainguru

I thought ICANN were doing the test bed "as we speak"?

But firstly, does the test bed come before or after the 8-9 month development cycle?

Whether it is a boon or bane, quick implementation is a remote scenario.

Re: Verisign response on DNAME or the other implementation.

I agree with DomainGuru. Let ICANN take it's time with IDN.IDN. IDN.com and IE7 are the biggest steps forward.

Re: Verisign response on DNAME or the other implementation.

Quote:

Originally Posted by domainguru

Don't discard so fast the possibility of having a free idn.idn out of your idn.com.

Re: Verisign response on DNAME or the other implementation.

Quote:

Originally Posted by thefabfive

I agree with DomainGuru. Let ICANN take it's time with IDN.IDN. IDN.com and IE7 are the biggest steps forward.

agree, assuming M$ don't do anything silly like disable IDN functionality in the proper release.

Re: Verisign response on DNAME or the other implementation.

Quote:

Don't discard so fast the possibility of having a free idn.idn out of your idn.com.

When people start taking about "giving" IDN.IDN to the IDN.com owners I get a little nervous. No one in the world would want to hand something this valuable to us and talk like this, if it gets ingrained in the policymaker's heads, could be a problem.

IDN.IDN should be considered an alias and not as it's own entity (assuming of course that DNAME is implemented). IDN.IDN is a way for non-English speakers to reach the proper IDN.com. IDN.com is real, IDN.IDN should be considered a tool for reaching IDN.com.

Re: Verisign response on DNAME or the other implementation.

Quote:

Originally Posted by thefabfive

IDN.com is real, IDN.IDN should be considered a tool for reaching IDN.com.

I agree; IDN.IDN should almost be thought of as the same idea as a redirect...

Re: Verisign response on DNAME or the other implementation.

Quote:

Originally Posted by thefabfive

IDN.IDN is a way for non-English speakers to reach the proper IDN.com. IDN.com is real, IDN.IDN should be considered a tool for reaching IDN.com.

Spoken like a true idn.com speculator...

Re: Verisign response on DNAME or the other implementation.

>The implications are quite broad and while it might be fairly straightforward for a
>regional ccTLD it becomes much more complex in gTLDs.

This, I feel, is speaking about political/operational implications rather than technical implications.

As such, there should be no reason that a test bed/development cycle (which is afterall only making sure the tech side works) shouldn't be running at the same time the political/operational implications are labouriously thrashed out in far away places that no one can afford to get to.

Re: Verisign response on DNAME or the other implementation.

Quote:

Originally Posted by domainstosell

I agree; IDN.IDN should almost be thought of as the same idea as a redirect...

Well there is the rub. If it is DNAME, it definitely is. If it is NS, it is not necessarily. I don't think anyone though is seriously going to be able to install a hundred sanctioned new extension into the root in the kind of of timescale that is being demanded. DNAME is a convenient body swerve for all of this. With DNAME, ICANN can effectively do as it pleases.

Quote:

Originally Posted by Drewbert

This, I feel, is speaking about political/operational implications rather than technical implications.

It all comes down to politics. This is why someone that has not been sanctioned to hand out new information fobs you off with an nebulous and ambigious load of crap. Almost a waste of time asking in the first place.

Re: Verisign response on DNAME or the other implementation.

We've talked a lot, but unfortunately, still come to no conclusion on the timeline. I think we may well put this aside until there's something more concrete.

Re: Verisign response on DNAME or the other implementation.

I am speaking from an uneducated position but why would it be difficult to have the .com translated into the equivqalent of whatever language the domain is being requested from when passing the server? Thereby achieving idn.idn through idn.com.

Armadillo

Re: Verisign response on DNAME or the other implementation.

Quote:

Originally Posted by Armadillo

This is known as dname. It is not difficult. What is difficult is for all the parties to come to a conclusion as to what to do.

Re: Verisign response on DNAME or the other implementation.

Quote:

Originally Posted by blastfromthepast

This is known as dname. It is not difficult. What is difficult is for all the parties to come to a conclusion as to what to do.

Yes, except he got his to's and from's muddled.