Internet DRAFT - draft-chung-idn-idnx
draft-chung-idn-idnx
IDN Edmon Chung & David Leung
Internet Draft Neteka Inc.
<draft-chung-idn-idnx-00.txt>
Intended Category: Informational June 2002
Internationalized Domain Name Transition (IDNX)
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The reader is cautioned not to depend on the values that appear in
examples to be current or complete, since their purpose is primarily
educational. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a strategy for domain name server operators
to prepare and transition their services for multilingual domain
names (IDN û Internationalized Domain Names).
The IDNX approach accepts that users with non-IDN aware applications
will be attempting to access multilingual domain names. Hence it is
the registry or domain operator's responsibility to provide an IDN
solution that resolves these issues to make it a seamless transition
experience for technically unsophisticated users.
In essence, the IDNX approach embraces a complementary server-side
implementation to smooth the transition. IDNX compliant domain
servers will successfully resolve IDN requests sent via non-IDN aware
applications, whether they are formatted in local encoding, UTF-8 or
an identifiable variant.
The IDNX approach also utilizes a dynamic CNAME mechanism to
provision for the sub-delegation of multilingual domain names to
hosts running non-IDN aware DNS servers.
Chung & Leung [Page 1]
IDNX IDN Transition June 2002
Table of Contents
Abstract...........................................................1
1. Introduction....................................................2
1.1 Terminology....................................................2
1.2 Assumptions....................................................2
2. Common Misconceptions & The IDNX Premise........................2
3. The reality of a Purebred IDNA Approach.........................3
3.1 Lengthy Transition & User Confusion............................4
3.2 Registry Responsibilities......................................5
4. Complementary Server-end Brute Force Resolution.................5
4.1 Resolving Domain Names.........................................5
4.2 Extent of Resolution...........................................6
4.3 Ambiguity Resolution...........................................6
4.4 Complementing IDNA.............................................7
5. Delegating Multilingual Domain Names............................7
5.1 Dynamic CNAME..................................................7
5.2 Setting up a Multilingual Domain Name at the Registry..........8
5.3 Setting up a Multilingual Domain Zone at the Host..............9
5.4 Complementing IDNA.............................................9
6. Security Considerations.........................................9
7. Intellectual Property Considerations............................9
8. References.....................................................10
1. Introduction
During the lengthy discussion at the IETF IDN workgroup, the question
about time-to-deployment is often being raised and considered a
critical consideration. However little word was said on any actual
solid transition path towards IDN. This document will provide a
comprehensive guide to the issues surrounding the deployment as well
as information on resolving them during the transition period.
1.1 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in RFC
2119 [RFC2119].
1.2 Assumptions
This document assumes that the reader has basic knowledge of the DNS
and IDN. For more information on the IDN discussions and background
knowledge checkout: http://neteka.com/en/pages/products/position.html
2. Common Misconceptions & The IDNX Premise
There is a common misconception among domain registries and
registrars that once a proposed IETF standard (in the form of an RFC:
Request for Comments) for multilingual and Internationalized domain
names (IDNÆs) is published; Registries will immediately be able to
accept registrations and deliver a working multilingual domain names
Chung & Leung [Page 2]
IDNX IDN Transition June 2002
to end-users. In fact, the publishing of RFCs for IDN is but the
beginning of a long transition towards a common and universal
multilingual namespace.
Another common misconception is that a server-end approach would
cause a lengthier transition. That however is only based on a server
protocol overhaul for IDN and not the use of a server-end transitory
solution. IDNX is specifically designed for the transition.
The premises of IDNX are:
1. To support the adoption of the open IDN standard.
2. To present a working solution that provides a seamless transition
to the IDN standard.
3. Understanding that the client only approach to IDN will not work
speedily because there is no effective distribution method and
will result in low initial acceptance and accessibility, causing
customer confusion, dissatisfaction, customer support issues and
ultimately slower adoption.
4. Be fully compliant with the IDN standard by preparing the
registry for multilingual domain requests sent via existing
applications as well as upgraded IDN (Internationalized Domain
Names) aware applications;
5. It accepts and addresses the fact that multilingual domain
requests will be successfully sent to the registry from existing
software and will resolve those requests instead of avoid them;
6. Provide a solution that will make multilingual domain names
functional immediately;
7. To allow the host for a multilingual domain name to use an
existing (BIND, etc.) DNS software by using only an ACE record
(only registry Servers need be updated or supplemented);
8. To complement a client end approach with a transitional strategy
on the server end;
In short, we understand that a server side approach to IDN is a
crucial component for the successful deployment of a Multilingual
Registry to ensure accessibility to multilingual domain names and the
seamless migration to the IDN standard. This document will outline
the approaches to the resolving of an IDN and how the IDNX solution
can both accelerate adoption and reduce the risk of deployment of the
IDN standard for registries.
3. The reality of a Purebred IDNA Approach
Simply put, ACE is a process whereby multilingual domain names are
converted into an alphanumeric string containing only A-Z, 0-9 and
hyphens ô-ô (e.g. bq--ad9ebbvfnqerv.com). IDNA mandates that this
transformation take place before an application, for example the
browser, sends a DNS request over the Internet to a registry name
server.
Chung & Leung [Page 3]
IDNX IDN Transition June 2002
Success of a ôClientô only approach has two inherent pre-conditions;
1. Firstly, all software programs that interact with a domain name
MUST be upgraded with the ACE standard (browsers, email
applications, html editors, audio/video streaming applications,
word processors, operating system tools, ftp agents, etc.) before
the prescribed IDN system would function universally; and
2. The success of IDNÆs will depend on the successful propagation of
the client software, which will be highly dependant on a) the
successful dustribution of client plug-in in the short-term and
b) the incorporation of the standard in next generations of
application software (e.g. IE ad Outlook)
3.1 Lengthy Transition & User Confusion
A key concern with respect to a client only approach to IDN is that
there are simply no efficient or effective means to distribute the
client plug-ins. Companies, who have been dedicated advocates of the
client approach to multilingual domain names failed to achieve a
critical mass of adoption of their respective client software even
with aggressive promotion for over 2 years now. And, the recent
demise of RealNames has made it difficult for registries that elected
to align their IDN strategy with RealNamesÆ anticipated strategy of
being a launch pad for client distribution.
Furthermore, even if we assume that a dominant software provider,
such as Microsoft, with their stranglehold on the browser and email
client market, was to introduce a new version of its Internet
Explorer and Outlook line of products with the IDNA client built in,
it will still take a considerable amount of time before these new
versions reach the majority of desktops around the Internet. Using
Microsoft IE 6.0 as a yardstick for new browser adoption rates, which
yielded an eye-popping 36% penetration within 9 months of its
release, the industry is still effectively looking at a minimum of
24-36 months or more before a critical mass of Internet users will
have adopted an IDN standard-ready-browser. That is not taking into
consideration the lead-time for Microsoft to release the next version
of their software, let alone whether IDN will make the cut for its
next version, and that the IDNA components are stable. This will
realistically add another 12 months to the process.
Under some very realistic assumptions, even if Microsoft incorporates
the IETF standard into the next version of Internet Explorer, less
than half of the worldwide Internet users will have a browser that
supports the IETF standard by the end of 2004. In short, even if
third party software vendors like Microsoft do adopt the standard and
Registries like VeriSign do put effort in promoting a client plug-in,
these combined efforts will still not achieve any meaningful
universality in 24-36 months and beyond.
Finally, the client side approach to internationalized domains is
especially susceptible to client plug-in software conflicts as
Chung & Leung [Page 4]
IDNX IDN Transition June 2002
providers scramble to push out these plug-in software applications.
Client plug-in providers may purposefully or inadvertently interfere
with how the browsers handle multilingual characters causing greater
confusion.
To summarize, the purebred client approach requires no changes to the
DNS infrastructure but does require fast and efficient distribution
of client software that supports the standard û as we have
demonstrated above this will be difficult to achieve. Registries
that cannot guarantee almost universal access to multilingual domains
from the start will likely experience support headaches and many
dissatisfied customers who are confused and frustrated because their
multilingual domain names do not work. Further, without universal
access the value of multilingual domains will be compromised.
3.2 Registry Responsibilities
Because the average Internet user is not expected to be technically
sophisticated and know that they have to upgrade their existing
applications (such as the browser) before using multilingual domain
names, it will become the registryÆs responsibility to provide a
multilingual domain deployment that is transparent to its users. In
other words, the registry should be prepared to accept and resolve
multilingual domain requests from users with existing software when
they deploy and offer multilingual domain registrations to
registrants.
4. Complementary Server-end Brute Force Resolution
Multilingual domain name requests sent by existing software
(browsers, etc.) will reach the registry server. Whether the
registry decides to resolve the name or not is the relevant question.
Server side solutions that resolve these domain requests provide an
easy transition to the IETF standard and user-friendly approach to
implementing multilingual domains. Client-only approaches that are
likely to result initially in lower resolution rates, and greater
customer confusion and are likely to cause support nightmares.
4.1 Resolving Domain Names
In general, there are three types of IDN requests that a registry
server will receive: 1. Domain in the form of UTF8 encoding; 2.
Domain in the form of its local encoding (GB, Big-5, JIS, KSC,
ISO8859-1..13 etc.); 3. Domain is in an ACE (ASCII Compatible
Encoding) format. Each of these types includes both the possibility
that the received request is in its pure form or that it is a variant
of the type. Because the application (browser or the operating
system) was not designed for multilingual domain names, even though
it does send out the domain request, it often tampers with the
characters before sending, causing the advent of a variant being
generated.
Chung & Leung [Page 5]
IDNX IDN Transition June 2002
4.2 Extent of Resolution
Type 1 requests, where a domain is sent in the form of UTF8 encoded
characters, are generally received from more recent versions of
browsers and operating platforms. These include Microsoft Internet
Explorer 5 and above, Netscape 6 and above and applications based on
the Windows 2000 or XP platform. These applications were designed to
deal with multilingual characters using Unicode, however, because it
was not specifically programmed for IDNs, it sometimes malfunction
when presented with such. The result is that a variant of original
UTF8 character is formed and sent to the DNS.
Type 2 requests, where a domain is sent in the form of local encoded
characters (GB, Big-5, JIS, KSC, ISO8859-1..13, etc.), are generally
received from earlier versions of browsers and operating platforms.
These include Microsoft Internet Explorer 4, Netscape 4 most other
applications based on the Windows 98 or earlier platform. These
applications were not designed to deal with multilingual characters
using Unicode at all and therefore will be sending out the IDN in its
local encoding. Mostly, the domain is also not tampered with before
sending; therefore a pure local encoding may be received. However
under some platforms and circumstances, it will also try to
reinterpret a multilingual domain name. The result is that a variant
of original local encoded character is formed and sent to the DNS.
Type 3 requests, where a domain is sent in the form of ACE encoded
characters (RACE, DUDE, UTF5, AMC-Z, etc.), means that the
application has been upgraded with an IDN client. Because of the
evolving standard depending on the version or provider of the client,
the type of ACE string may be different. Additionally, these client
plug-ins are susceptible to buggy code, as they are being created as
beta products by providers experimenting with the evolving IDN
standard. Misbehaviors caused by browsers and operating systems,
which are not taken into consideration by the client also gives way
to the creation of variants in ACE formats.
Even though variants are created as a derivation form the pure form,
these variations are consistent and predictable, and therefore can be
resolved definitively and uniquely. There is no guessing involved.
An IDNX capable server could be designed to handle both requests sent
in its pure form as well as its variants from the three types of
multilingual domain name requests. The extent of the coverage is
only dependent on the extent of research an implementer has put on
the subject and their understanding of the IDN issues.
4.3 Ambiguity Resolution
Another concern is for character encoding conflicts between the
various 8-bit encoding schemes (including UTF8 and local encoding
schemes). The IDNX solution suggests the handling of these issues at
the point of registration. On the registration side, the domain name
is definitively registered using Unicode, regardless of whether
Unicode or local encoding was used as input. The desired domain name
Chung & Leung [Page 6]
IDNX IDN Transition June 2002
is confirmed with the user at the interface, ensuring that the name
registered is accurate.
During the availability search, encoding conflict is checked to
ensure no existing domain name caused an encoding conflict with the
requested domain. In essence, it SHOULD maintain uniqueness of a
codepoint string regardless of its original encoding scheme. The
system SHOULD reject domain names on a first come first serve basis
for domains that will cause conflict with any local encoding or UTF8
string (or variants if applicable).
By taking care of both the domain registration and the resolution
side at a domain registry, IDNX can ensure a complete solution and
extensive coverage for multilingual domain resolution. Not only will
users with IDN aware plug-ins be able to access the multilingual
domain names offered by registries or domain operators with IDNX,
users who are using existing software, existing browsers will also be
able to successfully access these names, making it a truly seamless
and transparent transition.
4.4 Complementing IDNA
To complement the propagation of IDNA clients, IDNX servers could
also improve the download experience by dynamically prompting the
user for download when the first tries to access a multilingual
domain name. Because the IDNX solution includes a server-end
deployment, the server could be configured to act as a channel for
the IDN client at the point of access to multilingual domain names.
In essence, with an IDNX capable server, the registry would be able
to successfully intercept multilingual domain requests and offer the
user the option to download an IDN client plug-in. If the user
chooses to download the plug-in, then the domain would be resolved
using the ACE format. If the user declines the option to download,
IDNX, preserving the seamless resolution experience for the end-user,
would still resolve the domain.
5. Delegating Multilingual Domain Names
Besides being backward compatible with existing client side
applications, the IDNX solution also intends to make it backward
compatible for name servers hosting delegated multilingual domain
names. Besides resolving the IDNs, the other biggest challenge for a
registry in rolling out multilingual domain names is how domain
registrants could host it. With IDNX deployed at the registry level,
the delegated domain hosts SHOULD simply use their existing name
server (BIND, etc.) and load in the long term ACE as the domain.
They could also further delegate sub-domains to other hosts, just
like with the current English only domain names.
5.1 Dynamic CNAME
The ability to sub-delegate multilingual domain names to ACE only
hosts is achieved by using a dynamic CNAME mechanism to glue the
Chung & Leung [Page 7]
IDNX IDN Transition June 2002
multilingual domain name to the long term ACE equivalent at the
registry DNS server.
The following is a brief explanation on how the dynamic CNAME SHOULD
work:
- Application sends www.<ML>.example to DNS
- .example Registry responds with:
www.<ML>.example CNAME www.xx--ACE.example
- Application then uses www.xx--ACE.example to query the host
- Therefore the host will only have to setup the xx--ACE.example zone
While the registrant for a multilingual domain names will be able to
host their names with their existing DNS server software and be able
to create English sub-domains from it, if multilingual sub-domains
are desired, then the registrant SHOULD also make their system IDNX
capable.
5.2 Setting up a Multilingual Domain Name at the Registry
The concept of Dynamic CNAME is relatively simple, imagine the
multilingual domain name being setup at the registry as:
*.<ML>.example IN CNAME *.xx--ACE.example
xx--ACE.example IN NS ns1.xx--ACE.example
An IDNX compatible DNS will therefore successfully provide the
requestor the corresponding ACE record of a multilingual domain
request via a CNAME response, which is supported by regular DNS
resolvers.
In essence, no matter what the sub-domains may be for the
<ML>.example domain, it will be successfully sub-delegated to the
host server in its ACE name.
The setup of the different types of possible requests and variants
could also be conceptually imagined to be set up as:
*.<ML-Type1>.example IN CNAME *.xx--ACE.example
*.<ML-Type1-variant>.example IN CNAME *.xx--ACE.example
*.<ML-Type2>.example IN CNAME *.xx--ACE.example
The actual implementation of an IDNX compatible server however may
cause the setup to be different. For example, the implementation
SHOULD make the forking of the variants transparent to the zone
administrator, so the administrator only needs to provide one
definitive record, for example simply:
xx--ACE.example IN NS ns1.xx--ACE.example
Upon loading the zone file, the IDNX server should identify the xx--
ACE.example domain as a multilingual domain and fork the variants out
automatically for resolution purposes.
Chung & Leung [Page 8]
IDNX IDN Transition June 2002
5.3 Setting up a Multilingual Domain Zone at the Host
The multilingual domain name will simply be setup as a regular
English only domain name with the ACE record. For example:
xx--ACE.example IN SOA ns1.xx--ACE.example dnsmaster.xx (
2002062400
1800
900
86400
3600 )
NS ns1.xx--ACE.example
MX 0 mail.xx--ACE.example
ns1 A 123.4.5.6
www A 123.4.5.7
mail A 123.4.5.8
As you may see, it is exactly identical to what you would do for
setting up an English only domain.
5.4 Complementing IDNA
Furthermore, because the IDNX architecture for registries allows for
the delegation of IDNs in ACE format to non-IDN aware host servers,
this again complements the evolving client side standard whereby the
hosts do not necessarily have to upgrade their system for
multilingual domains.
6. Security Considerations
This document does not talk about DNS security issues, and it is
believed that the proposal does not introduce additional security
problems not already existent and/or anticipated by adding
multilingual characters to DNS and/or using ACE.
Although some may argue that multilingual characters create more
ambiguity issues and hence are more susceptible to confusion and
attacks, it is actually no more problematic than issues brought about
by the use of the letter ôOö and the digit ô0ö or the letter ôIö and
the digit ô1ö.
Because DNSSEC provides coverage for wildcard records, the Dynamic
CNAME feature will also not cause any additional security concerns.
7. Intellectual Property Considerations
It is the intention of Neteka to submit the elements of the Neteka
multilingual domain name server solution to IETF for review, comment
and/or standardization.
Neteka Inc. has applied for one or more patents on the technology
related to multilingual domain name server software and multilingual
email server software suite. If a standard is adopted by IETF and
Chung & Leung [Page 9]
IDNX IDN Transition June 2002
any patents are issued to Neteka with claims that are necessary for
practicing the standard, any party will be able to obtain the right
to implement, use and distribute the technology or works when
implementing, using or distributing technology based upon the
specific specifications under fair, reasonable and non-discriminatory
terms.
8. References
[IDNA] Internationalizing Domain Names in Applications,
draft-ietf-idn-idna, Feb 2002, Patrik Faltstrom,
Paul Hoffman, Adam M. Costella
[PUNYCODE] Punycode: An encoding of Unicode for use with IDNA,
draft-ietf-idn-punycode, Feb 2002, Adam M. Costella
[STRINGPREP]Preparation of Internationalized Strings,
draft-hoffman-stringprep, Feb 2002, Paul Hoffman,
Marc Blanchet
[NAMEPREP] Nameprep: A Stringprep Profile for Internationalized
Domain Names, draft-ietf-idn-nameprep, Feb 2002,
Paul Hoffman, Marc Blanchet
Authors:
Edmon Chung
Neteka Inc.
Suite 100, 243 College St. Toronto,
Ontario, Canada M5T 1R5
edmon@neteka.com
David Leung
Neteka Inc.
Suite 100, 243 College St. Toronto,
Ontario, Canada M5T 1R5
david@neteka.com
Chung & Leung [Page 10]
