i-DNS.net does not offer registration services, but deploys its IDN technology via its partners. Our technology encompasses all the above types of IDN. For a listing of our registrar, registry and strategic partners, please see:
http://www.i-dns.net/corporate/partners/partners.html

Status Report: Operator-based response

However, we do not offer full Latin script [Latin].lLatin] domain name registration services through any of our Registrar partners.

Status Report: Operator-based response

The names are globally resolvable through:

1) Client-side solution - iClient
IETF has recommended that NAMEPREP be done on the client's end till a standard is determined. Having struck a strategic technology relationship with VeriSign, i-DNS.net's iClient is downloadable off both our corporate websites to enable the resolution of multilingual domain names. iClient resolves multilingual email addresses and all types of multilingual domain names, including ML.com (by VeriSign) and ML.ML (by i-DNS.net).

2) Server-side solution - iBIND
For ISPs wishing to immediately and transparently enable their user base with resolution ability, they can patch their servers with i-DNS.net's iBIND.

Status Report: Operator-based response

Our core technology is embodied in two complementary products: WALID WorldConnect and WALID WorldTools™. WorldConnect is a client application which resides on the end-users' operating system and transparently handles the normalization and ACE transformation of multilingual domain names for resolution by the system's resolver. WorldConnect is currently being evaluated as a resolution technology as part of the VeriSign Multilingual Testbed.

WorldApp enables application developers to easily access and integrate IDN to ACE transformations into their applications. Because WorldApp is distributed as part of WorldConnect, an automatic and secure upgrade mechanism is intrinsic.

WorldTools is a toolkit of components for deployment at the registrar and registry's system to perform the same normalization and transformation at the time of registration. This toolkit provides a Java-based multilingual input method editor to support users who may not be able to render or generate particular scripts on their systems, and tools to support administrators of name servers, web servers, and other infrastructure systems.

All of these products have at their core an embedded runtime library called libIDN, which performs the actual normalization and transformation.

(1)Interim case:

a. Using NAMEPREP to convert IDN into English domain name(ACE encoding) for IDN resolving.

b. Setting up DNS(web) proxy to support IDN resolving. The DNS(web) proxy converts IDN into English domain name.

c. Supporting various zone file encoding in server side.

(2)Testbed case:

a. Modifying BIND software to support clean 8 bits (native encoding) and UTF-8 encoding.

b. Modifying related software: Apache, Squid, etc., to support clean 8 bits (native encoding) UTF-8 encoding.

i-DNS.net pioneered the development of the Internationalized Domain Name System (iDNS) technology, currently being adopted by more than 30 Registrar, Registry and Strategic Partners.

Status Report: Operator-based response

i-DNS.net will also continue to support and participate in the IETF IDN WG by sharing its experience and expertise with all WG participants without bias.

Please go to: http://www.i-dns.net/corporate/pressroom/papers.html# to view i-DNS.net's technology position papers.

In keeping pace of the IETF standardization process, i-DNS.net has taken an approach that addresses the widest possible technical possibilities in resolving Internationalized Domain Names, one of which might be the promulgated Standard by IETF. This ranges from Client-based to Server-based, and from DNS to Directory-based solutions.

Status Report: Operator-based response

VGRS accepts testbed registrations in the form of valid characters as defined by the Unicode code point list at http://www.verisign-grs.com/idn/unicode.html.

Thus the testbed will allow a registrant to register an IDN in all the languages that can be written in the following scripts: Latin; Greek; Cyrillic; Armenian; Hebrew; Arabic; Syriac; Thaana; Devanagari; Bengali; Gurmukhi; Oriya; Tamil; Telegu; Kannada; Malayalam; Sinhala; Thai; Lao; Tibetan; Myanmar; Georgian; Hangul; Ethiopic; Cherokee; Canadian-Aboriginal Syllabics; Ogham; Runic; Khmer; Mongolian; Han (Japanese, Chinese, Korean ideographs); Hiragana; Katakana; Bopomofo and Yi.

i-DNS technology supports all languages that are supported within Unicode. Some of our Strategic and Registry Partners (e.g. eNIC and VeriSign GRS) are already utilizing our technology to offer registration services in more than 30 languages.

Status Report: Operator-based response

For instance, some scripts lack accepted encoding standards e.g. Indian languages (Tamil, Telugu, Hindi). Scripts that lack input methods or scripts that are not fully supported by the native operating system can pose challenges.

However these are not IDN problems per se; Native language input method, necessary for users to access IDN, is dependent on Operating Systems and the availability of supporting applications. Unless you can get the language entered/displayed on a computer, there is no way that you can treat it under any IDN.

Status Report: Operator-based response

Since the incorporation of i-DNS.net, market research is constantly conducted for strategic planning and deployment purposes. The studies have few common revelations:

- Chinese, Korean and Japanese markets are Asia's largest, with extremely high demand for IDN services.
- Demand for IDN will grow at an exponential rate, alongside the exponential growth of Non-English Internet users and localized web content.
- Population of Non-English Internet users will significantly outweigh that of English Internet users.

Status Report: Operator-based response

We founded WALID based on two fundamental beliefs. First, that internationalized domain names are a necessity for the Internet to become a truly universal system that serves a diverse and global audience. Second, that our technical approach towards internationalized domain names, particularly as embodied in WALID WorldConnect, is unique in that it is deployable immediately and will not have a profoundly negative impact on the current operational and functional stability of the Internet.

Our experience with our customers has been that, for the most part, they are registering internationalized domain names because they find them interesting and valuable, and less so because they are trying to protect a brand or trademark. Our reach with registration services has been on a much smaller scale than VeriSign's testbed activities, and we would expect that more defensive registrations could occur as our volume increases.

We started doing it not just only from a defensive measure point of view. We also need to concern what our Internet community needs.

Prevent cybersquatting and requirement of use IDNs both are the registrants consideration.

To some extent, CNNIC offers CDN services is because others are offering the similar services.

Users register CDN is because to prevent cybersquatting.

i-DNS.net seeks to continually provide value-added services aimed at supporting the entire spectrum of the industry. Specific examples of such services that we have launched include professional registrar services and managed registry outsourcing services.

With regards the 2nd part of the question, i-DNS.net is seeing registrations of IDN by many SMEs and established Companies like Yahoo!, Acer, Asustek, Honda, etc. Establishing and protecting their online branding/identity is often a common proposition for them to register. We do not, however, know the extent of which of these are defensive measures against speculators.

Status Report: Operator-based response

WALID requires registrants to agree to terms and conditions in an agreement modelled very closely on the ICANN UDRP, and we are committed to supporting and following ICANN's lead with respect to the establishment of a uniform dispute resolution policy, as it may be amended from time to time.

We currently do not have any "sunrise" mechanism in place or a similar policy at this time. We would be interested to participate in any discussions concerning these matters for IDNS.

a. WHOIS measures: we require applicants to provide authentic contact information (including name of organization, location, postal code, telephone number, fax number, email address, etc.) and the confirmation for accepting the restriction of the Domain Name Resolution process;

b. Sunrise mechanism?To prevent cybersquatting;

c. Examination measures: we require our registrars to strictly observe the "Administration Measures on Chinese Domain Name Registration (trial version)"

d. CDRP mechanism: In regarding to prevent disputes in register and use CDN, CNNIC published "Chinese Domain Name Dispute Resolution (Trial Version)"in November last year. CNNIC also authorized CIETAC(China International Economy and Trade Arbitration Committee) as CDN dispute resolution institution, which can provide both sides of the dispute a convenient and equitable resolution method.

We agree to the principles of UDRP, while gTLDs and ccTLDs should have their distinctive characteristics in resolving the domain name disputes.

i-DNS.net endorses the World Intellectual Property Organisation's ("WIPO") Final Report of the WIPO Internet Domain Name Process (dated 30 April 1999) - a copy of which can be found at
http://ecommerce.wipo.int/domains/process/eng/final_report.html.

i-DNS.net's dispute policy at http://www.i-DNS.net/dispute.html is drafted & modeled along WIPO's recommendations and ICANN's Uniform Dispute Resolution Policy (UDRP).

In our Domain Name Registration Agreement, which all of our Registrars are required to adopt, we specifically warn potential registrants not to register trademarks that they do not have rights to.
However, there are no restrictions against generic domain names, so long as the generic name is available at the time of registration. We do not have any sunrise-mechanism in place.

Status Report: Operator-based response

WHOIS services must be internationalized if the domain names they hold are internationalized. One possibility is internationalizing the WHOIS protocol itself, along with clients and servers. Another is adopting the IDNA approach: IDNs would be stored in an ACE format and WHOIS clients would convert internationalized user input into ACE format before querying a WHOIS server.

VeriSign GRS is presently developing an IDN Whois service. In the interim, an IDN conversion tool is provided.

We offer WHOIS database for

1) solving technical problems,
2) transparency of the fairness of registration,
3) reference to DRP-related information, and
4) analysis in academic statistics study.

We offer CDN inquiring database; people can easily consult the domain name owner and relevant registration information.

Yes (only for [IDN.IDN] names of which we are the technology provider and Registry). Our Whois database has a publicly accessible function that provides information on domain names within our Registry.

Status Report: Operator-based response

Participation in the IDN testbed is open to ICANN accredited, IDN certified registrars only. The testbed nature of the IDN registrations as well as information on standards progress is available on the IDN Central Website (http://www.verisign-grs.com/idn/index.html).

As communicated in press releases and on the VeriSign GRS web site, it is important for registrars and registrants to understand that the Internet Engineering Task Force (IETF) has not finalized internationalized domain name standards. In the future, revisions to the Internet draft documents may cause:

• The registrant's domain name registration to become invalid and be deleted.
• Modification to the VeriSign GRS Registry's internal representation of the domain name to comply with revisions to the Internet draft documents.

Such occurrences will be resolved on a case-by-case basis, as they occur.

Since CNNIC launched its CDN system, we applied ourselves to inform CDN users the tentative nature of current IDN standards and testbeds.

i-DNS.net shares its marketing efforts with its Registrar partners, who have a strong in-depth understanding of their local markets. Marketing initiatives include online advertising, print ads on Business publications, etc.

i-DNS.net's enquiry support is extended to global Internet users, and we seek to address all queries on general topics related to IDN. e.g. questions on the coordinating bodies of IDN, questions on IDN standard, etc.

i-DNS.net is also actively educating the public on the benefits, availability and usage of IDN through the media. Our PR initiatives have generated hundreds of IDN-related news articles in various global and local publications.

Public Education on IDN is one of i-DNS.net's priorities.

Status Report: Operator-based response

(1) To develop IDN must consider about the local user's culture and customs , not just only solve technical problem. Thus, IDN's related management and policy are also very important.

(2) Due to the non-English country's users eagerly need of IDN, We suggest IETF IDN WG speeding the step of forming IDN related standards.

(3) Chinese as one of the non-English script, has the great majority population used in Mainland, Taiwan, Hong kong, Macao. So we strongly suggest the Chinese domain name (CDN), including [CDN].cctld and [CDN].[CDN], should let CDNC(Chinese Domain Name Consortium) to deal with local testbed. The experience and result of the local testbed could be as a reference to open up another global IDN TLDs

No further comment.

Status Report: Solution not just technical. User customs should be respected.

http://www.ejapandns.co.jp/

The top level domains thay are administering are ".kaish (in Kanji)", ".net (in Katakana)", and ".game (in Katakana)".

You can find some news articles in the following URL's though they are all in Japanese.=

http://www.ascii24.com/24/news/net/article/2001/04/20/625433-000.html?24

http://www.mainichi.co.jp/digital/coverstory/archive/200104/19/1.html

http://ascii24.com/news/i/serv/article/2001/07/18/628030-000.html

The above mentioned three TLD's are not authorized by ICANN. And they seem to have adopted the Zero Level Domain technique which may lead to the break of the Internet domain name space. I think you may call it one of the alternate roots.

Fortunately, I don't think it's popular here in Japan as of now. But it should not be allowed in the context of public trust on which ICANN is based.

Thank you.

i-DNS.net does not wish to comment on the intent of other IDN service providers, or whether they misrepresent their services to their publics.

However, misrepresentation is not a practice that we subscribe to. We firmly believe that where there are issues that can affect a service that is offered for sale, the respective publics should be fully informed at the point of purchase.

Currently, there are numerous providers of IDN services that claim IETF compliance, offering ML TLD strings. As we understand things, these companies provide domain names that resolve over the Internet through the current ICANN root.

i-DNS.net is one provider of these services, and we provide our customers with a way of resolving their names on the existing Internet, without "breaking" the Internet. We believe that our Customers, and our registrars, are fully aware of the features of our product, and what is required to use them in practice, hence we do not believe that we misrepresent in any way our services.

We believe that all IDN service providers should publicly articulate their approach to deploying IDN services (through white and position papers) and adhere to what has been posited. Any changes to their approach should be further documented publicly so as to empower Internet users with the necessary information to make the right decisions, when choosing a particular service provider.

Perhaps ICANN feels there is an "oversight" role for it to play in reviewing such documentation. However, this places ICANN in danger of becoming a regulator for all services on the Internet; why should they restrict themselves to IDN's?

Cleary the issue of "alternate roots" goes well beyond deployment of IDN's. "Resolution is a very broad topic, and covers a considerably wider area that "the root". For instance, Key words, browser plugs and a raft of other technologies and devices all contribute to resolution in different ways.

To keep stable operation of Internet is very important. The techniques of tunneling and local mirroring of DNS resolution servers are already existed in Internet. Current Internet DNS root server is the public trusted node, so every DNS server will refer to the root server for unknown domain resolving. If another one server is referred previously, it may or may not be a root server. But what is the exactly definition of alternate root? Something like Microsoft's "auto.search.msn.com", does it an alternate root?

We think a trusted single root manager is still need, even if the [IDN].[IDN] comes out. But before the IDN standard and managing rule are established, the testbed of [IDN].[IDN] for experimental purpose is also needed. ICANN should encourage the testbed if it is keep closed, stable and does not interfere the operation of current single authoritative root DNS infrastructure.