Subject: [idn] Re: Last Call: Internationalizing Domain Names In Applications (IDNA) to Proposed Standard

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Jun 2002 08:51:09 -0700

At 10:39 AM 5/29/2002 -0400, The IESG wrote:
>   Please send any comments to the
>[email-masked] or [email-masked] mailing lists by June 6, 2002.

Folks,

As the IDN working group record shows, the full problem space for 
internationalized text is broad and messy.  In spite of this, IDNA is a 
careful, constrained response to the key requirement for 
internationalization of Domain Names, namely enhancement of the Domain Name 
character set and definition of a means to encode those characters within 
the current DNS infrastructure.  The architectural principal for IDNA is 
well established, being essentially identical to the MIME Base-64 
character-encoding approach.

Unfortunately, the current draft specification of IDNA (-idna-10) has some 
deficiencies that make it incomplete for the task it is intended to perform:

1.  In addition to specifying an encoding scheme, IDNA makes a formal 
change to the DNS, by expanding the name space from a subset of ASCII to a 
subset of Unicode.  This change is not clearly documented in the IDNA 
specification.  The only relevant text is buried in a definition in the 
Terminology section and is easily missed.  Also, it is tied to IDNA, which 
is a particular encoding scheme for general Domain Name enhancement.

2.  The IDNA specification does not provide enough detail to permit its use 
for the most common Domain names, which is those used in URLs and email 
addresses.  That is, the constraints that fall under the domain name 
profile for "host names" are not carried through in IDNA.  Although the 
latest draft cites STD3, it does not provide the detail for applying it to 
IDN.  Hence a user of IDNA cannot be certain which Unicode characters are 
safe for use in host names and which are not.

3.  The specification imposes some user interface issues onto the 
protocol.  In particular, it defines multiple dot seperator characters, 
which is equivalent to creating multiple newline definitions or multiple 
at-sign or multiple "slash" definitions.

4.  The style of the current IDNA specification makes its use as a protocol 
specification challenging.  It is primarily tailored to programming, at the 
expense of direct specification of the protocol.  Throughout the document 
there are user interface and other non-normative comments such as 
discussion of the IDNA working group discussion history.  In the aggregate, 
these are at best distracting to the specification of the IDNA protocol and 
may even introduce ambiguities to the reader, although they could be useful 
compiled as separate, non-normative implementation guidance.

By way of suggesting a concrete means to quickly solve these deficiencies, 
I have issued two Internet Drafts:

         <http://www.ietf.org/internet-drafts/draft-crocker-idn-idn-00.txt>
and
         <http://www.ietf.org/internet-drafts/draft-crocker-idn-idn-00.txt>

These documents are intended as enhancements to the current IDN working 
group documents, rather than being replacements to those documents.  That 
is, they are offered strictly as contributions to the working group effort.

The majority of the text in these drafts are taken from the latest working 
group draft.  The salient changes were to add definition of formal domain 
name changes, vs. IDNA encoding changes, to complete the specification of 
IDN-based host name syntax, and to modifify the text to improve readability.

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Jun 2002 17:55:01 -0700

>         <http://www.ietf.org/internet-drafts/draft-crocker-idn-idn-00.txt>

The second citation should be:

         <http://www.ietf.org/internet-drafts/draft-crocker-idn-idna-00.txt>

d/

----------