[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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