Report of the Internationalized Domain Names Working Group–Responses to Survey A Posted: 28 August 2001

1. What different technologies currently enable the use of non-Latin scripts as domain names?

WALID	WALID, Inc. (WALID) considers that the deployed or proposed approaches to Internationalized Domain Names (IDNs) have focused mainly on four approaches: Upgrading the DNS protocol in certain ways to support the tagging of UTF-8 or codepage data in DNS packets, typically using some of the as-yet unused bits in the DNS packet header. This has been proposed in a number of IETF Internet-Drafts; Sending UTF-8 or codepage data (sometimes unmarked) on the wire using the existing protocol, and upgrading the authoritative DNS servers to store and process that data; Sending UTF-8 or codepage data (sometimes unmarked) to a DNS proxy server or other network agent, which performs an ACE transformation on the data and then presents the encoded name to the DNS for resolution; Performing ACE transformations directly on the DNS client node, in the resolver and/or the application layer. WALID is in favor of this approach to IDNs, and the approach is embodied in WALID's WorldConnect™ technology. Recently, other technology providers have begun to produce similar products.
Verisign	Standards to enable the use of non-Latin scripts as domain names have not been finalized. Broadly speaking, three different methods are currently in use: 1. Domain names are sent in a local encoding (such as GB, BIG5, SJIS, etc.) 2. Domain names are sent in a Unicode Transformation Format, such as UTF-8. 3. Domain names are converted to a "safe" representation using only the subset of ASCII characters currently supported by the Internet's infrastructure before sending. VeriSign Global Registry Services (VeriSign GRS) will conform its testbed to whatever standard emerges from the IETF process.
Neteka	There are in general three approaches to multilingualize the domain name system: Brute Force Approach - the DNS was designed to transport domain name characters in unsigned octets. Therefore, the protocol itself is actually capable of carrying 8bit information. The reason for restricting it to the US-ASCII scheme is simply for backward compatibility issues at the time it was devised. While the DNS has been arbitrarily constrained to English only alphanumeric names, implementers were not advised to reject names outside of the constraints, because the DNS will ultimately determine the existence of a domain name through its hierarchical search. It is possible therefore to force 8bit character information (such as UTF-8 or local encoding schemes: Big5, GB, JIS, etc.) through the DNS and existing implementation experiments indicate that root servers and middle-wares are usually unaffected. Protocol Extension Approach - An approach to solve the multilingual DNS problem is to introduce additional flagging or tags within the DNS packet to alert servers of the encoding scheme used by the request. Whether it is an encoding tag or simply a multilingual flag, the protocol approach utilizes the bit format within the existing DNS packet to notify the receiving end of the context of the domain name in question. A number of drafts have been proposed at the Internet Engineering Task Force (IETF) discussion on multilingual domain names, including the DNSII mechanism [DNSII-MDNP], utilization of EDNS to signify multilingual labels [IDNE], use of the reserved header bits [UDNS] as well as the introduction of a new DNS class for universal characters [ClassUC]. While there are relative advantages for the different proposals, DNSII supports the use of multiple encoding schemes, IDNE utilizes the newly standardized EDNS mechanism for DNS extensions, UDNS makes it possible for information to be tunneled all the way to the authoritative server and the introduction of Class UC could effectively create a coherent but entirely new namespace. ASCII Conversion Approach - The allocation of pain, or in other words where most effort for the use of multilingual domain names should be put drives the discussion towards an ASCII conversion approach whereby the legacy servers and transportation protocol does not need to change and that all multilingual character information are transformed into ASCII Compatible Encoding (ACE) formatted DNS requests. The assumption for an ASCII conversion approach is that all existing users on the Internet would upgrade to a multilingual aware DNS resolver, which would perform a standardized transformation mechanism to transform multilingual characters into alphanumeric strings that would fit into the original DNS specifications. In addition to transforming the multilingual characters to ASCII strings, an in-label identifier is usually appended to the domain name. For example, the Row-based ASCII Compatible Encoding [RACE] scheme, calls for the use of a "bq--" prefix. The common objective for all ACE schemes is to represent multilingual characters in alphanumeric form, fitting names within the current character constraints of the DNS. Each has a slightly different transformation mechanism, from a simple hex dump such as TRACE [DNSII-TRACE], to multiple compression scheme approach such as RACE. Besides the three main approaches, it is also possible to have a hybrid approach that mixes and matches the different technologies. It is also Neteka's opinion that the best strategy forward to deploy multilingual domain names consists of a hybrid of all three approaches and contemplates a phased transition: Short-term: Brute force approach - with the brute force approach, registries could immediately offer functional multilingual domain names to satisfy user demand. Neteka's technology allow the use of UTF8 as well as any other local encoding schemes (Big5, GB, JIS, KUC, etc.) to be resolved at the server without requiring any client side reconfiguration or plug-in. Mid-term: ASCII Conversion approach - a server end ASCII conversion approach is best used as a consolidation strategy for the different IDN solutions. It offers a common platform for the convergence of the technologies and provides a smooth transition and migration from the existing system (including with brute force multilingual), to a longer-term solution. Neteka's technology utilizes both RACE and TRACE as a platform for administration for multilingual names in brute force format, ASCII converted format as well as protocol extension (mode bit flagging) format. Long-term: Protocol Extension approach - for a longer-term solution, a protocol extension mechanism is generally considered the best approach because it eliminates ambiguity by clearly identifying multilingual names and does not compromise the efficiency of the domain system. Neteka's technology employs the DNSII bit flagging approach as well as the EDNS approach to transport and identify multilingual requests. The DNSII approach also allows the tagging of the encoding of the requested string, making it more precise and effective. With all three approaches pre-installed into Neteka's NeDNS, it is immediately deployable as a server end solution for registries to offer multilingual names, and prepared for the migration towards a longer-term solution, whatever stream it might turn out to be.
Register.com	Two general types of technologies attempt to enable the use of non-Latin scripts as domain names. The first of these approaches involves the transmission of native encodings as part of the DNS labels used within queries and/or responses. Native encodings are character encodings, such as ISO-foo or Shift-JIS used to represent non-Latin scripts. These encodings are generally 8-bit and always involve the use of characters outside those permitted within DNS labels by RFC 1034 [RFC1034]. The second type of approach is the conversion of IDNs into a domain name that conforms with RFC 1034. These approaches involve the use of ASCII-compatible encodings (ACEs) of non-Latin scripts. Generally, ACE-based proposals involve both the compression of non-ASCII data as well as a transformation into an RFC 1034 compliant string. For both of these approaches, various parties have proposed a variety of specific implementations. Internet Drafts currently describe several ACEs, as well as various approaches that describe the use of ACEs within various parts of the DNS. Different approaches using 8-bit character transmissions within the DNS have also been described, including on-the-wire transmission of native encodings as well as common formats such as UTF-8. Finally, some more radical approaches, such as the creation of a new DNS class or the use of a new directory layer to replace traditional DNS functionality, have been suggested.
JPNIC	We follow IETF IDN WG discussion. Application solution complies the IDNA architecture, with NAMEPREP and ACE.
TWNIC	(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 convert IDN into English domain name. c. Supporting various zone file encoding in server side. (2) Test bed 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) and UTF-8 encoding.
Brunner Williams	Two basic mechanisms enable the use of non-Latin scripts as domain names: encapsulated transport of extensions to the standard ASCII LDH character repetoire, also called "ASCII Compatible Extension" labels ("ACE labels"), but more correctly described as "Encodings Contained in ASCII", and native transport of extensions to the standard character repetoire, also called "binary labels", and "utf-8 labels". Both mechanisms rely upon the Universal Character Set (UCS) for a single ASCII preserving character set containing a large, but incomplete, repetoire of non-Latin characters.
Anonymous B	Adopting "multi 8-bit encoding" solution Adopting ACE solution Adopting "Directory" Solution Adopting EDNS resolution
Malenfant	Favorite is ACE
i-DNS.net	It is our understanding that the following are the more well known technology providers in the Multilingual (ML) field: i-DNS.net Alldomains.com CNNIC JPNIC NativeNames Neteka NU/WorldNames ThaiURL TUCOWS/Open SRS TWNIC WALID Status Report: Server-based, client-based and hybrids

2. What are the strengths and weaknesses of the technologies referenced in Question 1? Please give concrete examples.

WALID	A number of the proposed approaches described above treat the problem of IDN as if it were a 'DNS protocol problem', instead of a 'domain name problem'. That is to say, if the DNS protocol or infrastructure can be changed to support non-Latin scripts, then the problem would be solved. The rough consensus of the technical community, however, is that this approach is fundamentally incorrect, and perhaps the approach stems from a view that the only applications running on the Internet that need to be considered are web browsers and web servers (and sometimes only particular web browsers or servers). WALID would suggest that any approach to IDNs must take into account the entire deployed base of protocols, applications, and implementations that run on the Internet today, many of which are crucial for ensuring the stability, security, and operation of the network. Many of these protocols and implementations will not support characters outside of the LDH (letters, digits, and hyphen) set, either in forward or reverse resolution contexts. These fundamental issues aside, approaches that focus on changes to the infrastructure, either by deploying a new protocol, new servers, or new types of server applications face the inertia associated with the deployed nameservice infrastructure. The DNS is everywhere, and attempting to make significant changes to the DNS as a whole would likely take at least a decade for complete deployment, risking the creation of islands of dis-connectivity in the process. Infrastructure-based approaches also suffer from the problem that updates are difficult to deploy. In this respect, one need only consider the large numbers of very old BIND distributions still in operation with serious known security vulnerabilities. The approaches above that would send Unicode data directly (typically in the UTF-8 encoding) also ignore the issues relating to name equivalence, and ultimately would create a serious security problem, given that many applications and protocols rely on the DNS for performing authentication and authorization checks. Many Unicode codepoint sequences, which are visually identical, can be different at a binary level, creating the opportunity for a malicious user to fool someone into connecting to a different host than the one they think they are connecting to. At a more basic level, without some sort of canonicalization step during resolution, many users will have a difficult time making IDNs work reliably. Within the IETF, this requirement has been called the 'business card test'. WALID's approach to IDNs, currently in use as part of the VeriSign GRS multilingual testbed, is to perform a canonicalization and transformation process of the IDNs on the end user's system. IDNs are normalized to address the equivalence problem described above, and encoded using a transformation algorithm from Unicode into the subset of ASCII permitted in DNS host labels. IDNs that are presented to the DNS for resolution thus use the same range of characters as standard domain names. The significant advantage to this approach is that no changes are made to the deployed base of infrastructure systems, and the operational stability of the network is not compromised. Our experience in working with ccTLD registries has shown that infrastructure-based approaches, by contrast, are quite unworkable, both because of the inertia associated with the DNS resolution infrastructure and the large numbers of web proxy servers that are on the network. To deploy the ACE-based approach completely, applications which process DNS hostnames will need to be upgraded to handle IDNs. In the short-term, a mechanism must be widely deployed to enable immediate resolution of IDNs in the applications that end-users use most often, such as web browsers and e-mail applications. WALID is addressing these needs by making freely available for download its WALID WorldConnect™ technology, to enable immediate resolution of IDNs, and its WALID WorldApp™ to enable application developers to incorporate standard IDN transformation capabilities into their applications.
Verisign	Methods one and two above involve an application sending binary (i.e., non-ASCII) data through an infrastructure not designed to handle it, which certainly has the potential to cause problems. Application protocols, such as SMTP, call for domain names to be encoded in ASCII. Not all DNS resolvers and name servers are "8-bit clean" (i.e., able to handle binary data without issues). The deployed base is huge, with endless combinations of components, and it is impossible to test every scenario for its ability to handle binary data. We do not know of any completed studies, although MINC is planning such testing. (Please see http://www.minc.org/WG/testing/interop/.) For this reason, the IETF Internationalized Domain Name (IDN) Working Group has focused on the Internationalized Domain Names in Applications (IDNA) solution, which involves transforming internationalized domain names (as described in method three above) at the application level, so that they can be sent in application protocols and through the Internet's DNS infrastructure in a known safe format.
Neteka	Brute Force Approach - The advantage of this approach is that multilingual names could be deployed immediately at the server end to parse the multilingual name information and be reachable by a good percentage of users over the Internet. However there are with it also a considerable number of disadvantages that could cause inconsistent responses. These include character encoding conflicts as well as proxy and application blockages. Character encoding conflict is one that is particular prominent. The same encoding value could represent entirely different characters if a different encoding scheme is used. Conversely as well, the same characters might be represented with different encoding values under different schemes. Both of these issues lead to problems for the DNS where names must be unique and that the user expects to be transported to the same domain regardless of their input mechanism. Protocol Extension Approach - The common advantage of using a protocol approach is that the efficiency of the DNS is not compromised at all and that there will be no ambiguity as to the exact characters a domain name query is referring to. Also, with the introduction of an extension, versioning and future extensions could also be built in. In essence, a protocol extension approach is generally considered a better long-term solution for multilingual domain names. The common disadvantage of the protocol approach however is that it requires changes and upgrades from both the server-end as well as the client/application-end. This may result in the slower adoption of the system. ASCII Conversion Approach - The most prominent advantage for using an ASCII conversion scheme is that no changes is necessary in the server end because they will continue to expect and react to request that are formatted within the specifications of the original DNS standards. Conversely, the major disadvantage is that users that wish to use multilingual domain names must consciously upgrade their software to be able to reach the multilingual domains. The average user however is not likely to be technically sophisticated and would expect multilingual domain names to function the same as English only ones. Also, it introduces an additional procedure in domain resolution and takes away the feature of the DNS to keep the transportation format consistent with the presentation format of domain names. Hybrid Solution - It makes most economical sense for implementers to tackle the issue with an all inclusive hybrid approach because the efforts in development of the solution will not become totally emaciated. On one hand, the inclusion of a brute force approach ensures that once multilingual domains are deployed, a good number of users could immediately be able to access and utilize these names. On the other hand, more alert or early adopters would likely embrace the ACE technology and already have converters installed, therefore, to take care of these requests, the database should include an ACE formatted record. Finally, the system should be made aware of eventual protocol approach where the incoming packet would effectively announce the exact encoding scheme and format of the multilingual name. By developing a three-fold strategy, the implementer may be able to assure that it will be prepared for any situation that might transpire out of the dynamic standardization process now underway. As the Internet matures, it should no longer be a purely technology push mechanism for implementing new features, but should also consider the customer pull factor. In the hybrid deployment model, first the brute force approach is used so that registries could begin allowing registrants to obtain functional multilingual domains and use them immediately without any client-end reconfiguration. Only the registry name servers and the registrant's hosting server needs to be upgraded. As the need for accessing multilingual domains increase, users will be more aware and knowledgeable of using the ACE approach, which will make provides a good consolidation towards a common protocol and makes administration much easier. Eventually, this would encourage middleware and other applications to upgrade to the protocol approach to make the entire process much more efficient and truly multilingual aware.
Register.com	The advantage of 8-bit character transmission is that these approaches seem to be the most simple and elegant solutions. These approaches allow fairly direct representations of IDNs and may allow DNS data to be human-readable for those with terminals capable of recognizing and displaying the relevant character encodings. Unfortunately, although the DNS protocol itself allows for the transmission of 8-bit domain name data, many of the application protocols that rely on the DNS were not designed to handle such domain name data, and these protocols would likely need to be individually re-designed in order to provide IDN capability. ACE-based approaches generally provide a high degree of compatibility, because they continue to use RFC 1034 compliant labels to represent all DNS data. Some ACE-based approaches have been designed which move all IDN work to the application or local resolver, and as a result require no modification of the name servers which are currently running. Such an approach allows individual users to essentially "opt-in" to the use of IDNs by installing updated software on their computers without impacting other users or affecting the stability of the network at large. The more radical approaches mentioned above offer the potential for significant elegance and potentially large amounts of innovation, but the time to implement such solutions is likely to be unacceptably long.
JPNIC	Strengths: It can be realized with current protocols. Weakness: It reduces the string size of each label. It requires character set / encoding conversion.
TWNIC	Test bed case has the following strengths and weaknesses. Strengths: (1) It does not need to download client software. (2) It does not need to proceed ACE conversion on client side. (3) The zone file is readable for administrator. It is easy to maintain zone file. Weaknesses: (1) Some Chinese characters contain '\' '@' codes that makes Internet application confused. (2) Applications (like Bind, apache, firewall...etc) do not support clean 8 bits DNS data.
Brunner Williams	The label length is limited to 63 bytes. ACE allows up to 17 to 19 characters under the best conditions. UTF8 allows 21 or more characters. Labels are "visible" outside of the resolver-nameserver context, e.g., in email headers and bodies. ACE is not ASCII preserving, ACE transformations of names containing Latin characters not in ASCII, or non-Latin characters, bear no resemblance to the original name, even if only one non-ASCII character is present, e.g., umlaut. This feature is absent with UTF8, due to its ASCII preserving property. Labels are "processed" outside of the resolver-nameserver context, e.g., in email headers. ACE encapsulates extensions to ASCII in ASCII, resulting in no requirement for change to infrastructure such as mail transport agents which route mail based upon domain names in mail headers. UTF8 requires changes to infrastructure such as mail transport agents which route mail based upon domain names in mail headers. This change is frequently described as "8 bit clean processing".
Anonymous B	a. Advantages: Break through the limitation of current DNS protocol and size of domain names Disadvantages: Alters the DNS and relevant applications b. Advantages: No need to alter the current DNS, a technology with good interoperability. Disadvantages: Alters relevant application of DNS, awkward expressive performance in displaying and relevant applications, has more limitation on the length of domain names. c. Advantages: Leave some of the difficult problems on the representation layer Disadvantages: Need to modify applications related to DNS, need to add additional directory inquiring transactions. d. Disadvantages: the application scale is not broad.
Malenfant	DNS clients ACE unaware would look up entries exactly DNS clients ACE aware, would display IDN characters, but convert and submit transparently in ACE format DNS servers would be ACE unaware, and simply store ACE entries "as is", therefore requiring no change
i-DNS.net	i-DNS.net's technology has been active on the Internet for 3 years, beginning with a Pan-Asian test bed strategy; we stand behind our product which we can say with confidence, that it runs across the current Internet without causing it to break. i-DNS.net is the Technology Enabler and Resolution Partner-of-Choice to VGRS in the Multilingual Testbed. Our technology is in use by major Registrars like Register.com, Melbourne IT (INWW), interQ; as well as ccTLD Registrars handling .tv, .cc, .com.au, .la and .ai. We have established affiliations with industry organizations (IETF, APNG, APTLD, APIA, PBEC, W3C) and in-country players worldwide. Most importantly, i-DNS.net is the pioneer of the Internationalized Domain Name System (iDNS), the First Registry for Fully Multilingual Domain Names, the industry leader in terms of market penetration and has the longest operating track record since 1999. As part of our corporate objectives, we aim to provide a technology that remains compliant with the workings of the IETF; right now this means Client side and ACE based, and I-DNS.net technology is fully compliant with this. WALID have patented an IDN client solution and we understand this has raised some concerns to the IETF IDN working Group. Native Names (and a few others) provide Server Side solutions only, are would (in our opinion) not be compliant with IETF. Status Report: Server-based - no client intervention required but long assimilation by servers worldwide. Client-based - NAMEPREPed on application, as per IETF but require installation.

3. Are there more problems relating to particular scripts? Why?

WALID	The IETF IDN Working Group and the Unicode Consortium have been investigating the complexities associated with introducing non-Latin scripts into the context of DNS hostnames, and attempting to ensure that end-user expectations are met. We fully support the work of these two expert organizations in this area.
Verisign	Experts in these languages and scripts are in the best position to answer this question.
Neteka	In general, scripts with more local encoding schemes are more problematic initially for quick deployment of multilingual domain names. Other language issues are local script dependent. For example, there is the traditional and simplified Chinese issue. Part of the debate is whether a folding or mapping should occur automatically and built into the IDN protocol. This coupled with conflicting local character encoding schemes also makes the deployment of Chinese, Japanese and Korean scripts more difficult. Neteka's perspective on the Chinese character folding issue is that it should be a policy matter and controlled during registration and be dependent on the registry policy. ICANN should however provide guidelines as to what the issues are and suggest a number of alternatives to solve the problem. Other languages also have their own language issues such as Arabic, where spaces within phrases changes the meaning and the form of a character, Hebrew where characters could be omitted, etc.
Register.com	Essentially, the more different scripts are from traditional Latin scripts, the more likely problems are to occur. Languages such as Chinese and others that use the Han ideographs can be problematic due to the sheer size of the character repertoire. Some languages have a large number of encodings to represent essentially the same character set, which can make it problematic to identify and transform raw data into a common, universally understood format.
JPNIC	ACE requires Unicode as its base character set, but many PCs use local character set such as JIS. It causes normalization problems due to character set conversion, that is 1 to N mapping.
TWNIC	The second byte of Big5 encoding characters include ASCII encoding range, it may make DNS response error data (DNS software is case sensitive in ascii character)
Brunner Williams	European scripts, normally comprehensible with diacritical simplification become "ASCII gibberish" under ACE transformation. Scripts which use European characters and non-European characters have very poor ACE length properties, as ACE length optimization relies upon code page utilization.
Anonymous B	a. Sequence of Chinese Domain names: Chinese language is totally different from Latin in word and sentence structure. b. The Simplified - Original Chinese character mapping: Chinese characters have two writing forms to which corresponding each other. For Chinese people, this kind of correspondence is as same important as the Case folding to ASCII domain name users. c. The correspondence between "." & "?". The presence of such problem is due to the characteristics of Chinese input method, and the problem should be resolved to fulfill users' needs.
Malenfant	multiple endcodings (e.g. traditional and simplified Chinese, Arabic space phrasing, Hebrew omitted characters), could be resolved by manual entry of the multuple versions into the DNS at registration time
i-DNS.net	The IETF working group places special emphasis on conversion from Localè Unicode à ACE. It is script (not language) based, and the NAMEPREP process deals to the various nuances of each script. Standing back, we see the following issues Some scripts have no INPUT METHOD ENGINE (IME) which means that it is impossible to enter the language into the computer (e.g. some Indian scripts) Along a similar theme, some script lack a font renderer, so they cannot easily be displayed on the screen Some languages have yet to have standardized scripts Some languages have multiple scripts; in which case NAMEPREP needs to support consistent canonicalization and be case-folding (often an area of political debate amongst different linguists) Status Report: As above

4. To the extent there are weaknesses in the technologies, what groups are working to develop solutions?

5. What are the different solutions under consideration? Which are the most promising? How much longer will it take to develop a solution that works?

6. Currently there are no accepted standards for IDN. Is this because there are competing technologies, or because the underlying problem is sufficiently difficult that a "best" solution has not yet emerged?

7. Do the existing "testbeds" and pre-registrations help or hinder the resolution of the technical issues relating to IDN? In what manner? Would the testing impact the ongoing operation of the Internet?

8. Are natural languages so complex, rich and varied that a true IDN system that responds completely to user expectations is beyond current technological capability? Can the problem be solved incrementally in a manner that does not interfere with the operation of the entire domain name system?

WALID	The IDN problem in our view is not one of natural language, but rather one of adding support for a wider range of scripts to be used as identifiers in the DNS. As such, issues involving natural language and the often context-sensitive expectations of users are outside of the scope of the IDN-related efforts currently underway. Some within the community have proposed creating directory service layers above the DNS to meet the expanding needs, and we strongly encourage and support any work in this direction. Natural language issues are language- and locale-specific, and any proposals to address them should be developed based on participation by native members of the locale as well as general linguistics expertise.
Verisign	The IDN Working Group is already developing a technical solution to support a true IDN system. As noted above, we support the introduction of IDNs in a phased manner that does not risk interference with the operation of the DNS.
Neteka	This depends on the perspective of what constitutes a "domain name". Some technical persons maintain that a domain name is nothing more than a string of characters for the identification of a resource over the Internet. Neteka however believes that domain names have evolved from its origins to represent an identity of a person or a corporation on the Internet, whether it is being used as part of an email address or simply a web address. Natural language rules can definitely be introduced to the DNS, Neteka's technology have shown that the use of phrases, punctuations and even spaces are possible. Therefore a fully natural language domain name is possible. However, it is important to also understand that the domain name system is useful because of unique names and this rule should not be violated or confusion would occur. The same phrase must result in the same resource regardless of which locale or platform it is accessed from. This means that certain user education is required to understand that Mikeshoes.tld may not be the same Mikeshoes in your local mall.
Register.com	The domain name system was never intended to serve as a directory service with the capability to consistently find the appropriate result to a natural language query. Although the original design of the DNS includes certain characteristics which are designed to reduce language-related errors (for example, case folding, or even the original limitation of domain names to use only ASCII characters), it still is not capable of distinguishing between variants of words (e.g. "color" versus "colour") or appreciating the other subtle nuances of language. Regardless of the IDN solution that eventually emerges, it will be important to educate users regarding the use of the Internet. A good IDN solution will not solve natural language problems, but will allow many more users to take advantage of the Internet using their native language and their native character sets.
JPNIC	We believe that IDN doesn't introduce 'languages' to DNS, but introduces non-alphanumerical scripts or characters.
TWNIC	Usually natural languages will not be a domain name, user may use natural languages on search engine to find out some data. But proper normalization of DNS is required even it is very difficult.
Brunner-Williams	The DNS uses identifiers, not languages or words, though lots of words in lots of languages are used (in ASCII transliteration) in the DNS as identifiers. DNS labels are not general purpose objects for unconstrained writings, and the question reflects the (unfortunately widespread) misunderstanding concerning the fundamental properties of "identifier and lookup", wishfully substituting "word and search" in their place.
Anonymous B	We can find a progressive way to solve the problem.
Malenfant	yes, DNS is "identifier" only. Natural language queries could use web (http/url) or LDAP search to return identifier, for subsequent lookup in DNS system
i-DNS.net	Natural languages are complex. However, a workable and acceptable solution (i.e. one where non-English speakers can use their own language for domain names) does not need to perfectly cater for every singly nuance in a language. Compromises can be found (such as the substitution of space by the hyphen in ASCII domain names). In our opinion, most languages could be implemented in a way that provides very high utility over ENGLISH by dealing with 95% of the language issues - the remaining 5% would be out of bound and not catered for. Once more, a clear expression to the consumer is required so that they understand what they purchase. i-DNS.net believes it has developed a solution, which adequately satisfies market expectations of a true IDN system. And yes, it can progress incrementally without disrupting existing DNS operations. Status Report: Dichotomy between identifier and identity

9. How do different technologies affect the size limitation of domain names? What, if any, are the possible solutions?

WALID	Domain name segments are limited to 63 octets per segment, and an overall domain name length of 255 octets. In the context of the ACE-based proposals, Unicode codepoints can expand to multiple octets, thus reducing the number of actual non-Latin characters that can be used in a domain name. Even in non-ACE proposals (particularly those that rely on UTF-8) this same issue exists. There are a number of proposals under consideration by the IETF IDN working group to address this issue through efficient encoding of Unicode sequences. The challenge in this area is to find an encoding algorithm that is both very efficient yet relatively simple to describe and implement. The current draft before the IETF IDN Working Group ACE design team comes very close to meeting these requirements.
Verisign	Domain names are limited to 255 octets in length and individual labels (i.e., between periods) are limited to 63 octets. This is a fundamental limitation of the DNS protocol and cannot be changed without altering the DNS protocol. Different representations of different character sets require more or fewer octets depending on their design. For example, UTF-8 is a variable length encoding of the Unicode character set. In a given number of octets, some scripts require more space than others. The IDN Working Group has been sensitive to this issue during the design of the various ACE algorithms that are candidates for inclusion in the final IDN standard. A requirement of the final ACE algorithm is a roughly equal treatment of all scripts in Unicode.
Neteka	Brute Force Approach - utilizes existing packet format therefore will only allow a maximum of 63 bytes. Depending on the byte length of the character encoding scheme used, the number of characters possible could range from 63 to 15. Protocol Extension Approach - new size limit could be introduced so length can become a non-issue. ASCII Conversion Approach - utilizes existing packet format. Depending on compression scheme, domain length per label ranges between 15 - 20 characters.
Register.com	Because they transform eight bit characters into what is approximately a five bit (37 possible values) storage format, ACE-based solutions generally reduce the number of native characters that may be present within a single DNS label. Most of the existing ACE proposals contain compression mechanisms in order to increase the size of the native domain name as much as possible.
JPNIC	As answered in Q2, ACE reduces the size of each label. Therefore ACE must involve effective compression algorithm. JPNIC is evaluating many ACEs and contributing to IDN WG ACE team.
TWNIC	There is more length limitation on ACE encoding. Native encoding (local encoding like big5) has less length limitation on domain names.
Brunner-Williams	See the response to Question 2.
Anonymous B	Both multi 8-bit encoding and ACE can affect the size limitation of domain names. One of the resolutions is to expand DNS protocol.
Malenfant	encoded labels longer than 63 chars could be resolved through using more levels, one per word or syllable for instance. 255 chars overall should be adequate
i-DNS.net	The ASCII DNS already imposes size limitations, probably as its original designers ever imagined that it would be used today to identify name of companies etc. The IETF strategy Localè Unicode à ACE often requires more that one ASCII byte to represent each character so this means a ML DNS does not allow such long strings. Compounding this, some countries do not use acronyms to the extent that we do in the English speaking world (e.g. Arabic), preferring to register the full company name. IETF's proposals do deal with the size issue, and it is important to note that DUDE has some advantage over RACE in this regard. However, it is also important to note that regardless of technology restrictions, customers need to understand what is and is not achievable in a ML DNS. The fact that a ML DNS implementation does not cater for the full 64 character DNS string will not invalidate its utility. Perfection is a laudable design goal, but in reality most countries just want to use their language now, and 80% is better than 0%. Status Report: Existing Latin-based DNS limitations

10. Do IDNs pose special problems for the technical operation of WHOIS databases? If so, what problems? What are the possible solutions?

11. Are any IDNs related technologies covered by patents or other intellectual property rights? If so, will this have an affect on the implementation of IDNs?