At 10:39 AM 5/29/2002 -0400, The IESG wrote:
> Please send any comments to the
>iesg@ietf.org or ietf@ietf.org 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:dave@tribalwise.com>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850