[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Document Status?
At 09:36 AM 8/25/2002 +0200, Erik Nordmark wrote:
The second set of last-called documents (IDNA, punycode, and nameprep) still
have some IETF last call issues to resolve. The resultion will be in the form
of an added applicability section in the IDNA document. There is
still some word-smithing on that section, after which the documents will
be ready to be discussed by the IESG as a whole.
One last try... Having not yet seen any detailed response on the matters I
put forward some time ago, I will raise them again.
Your note implies that the IESG does not agree that the current IDN
specification suffers the following, basic deficiencies:
1. 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.
We usually document such major changes to basic protocols rather
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
This means that someone registering an IDN domain name for use in
email addresses and web addresses cannot know the exact set of valid IDN
characters avalailable for use.
If this interpretation of the specification is correct, IDN WILL
If this interpretation is not correct, it would help for someone
to explain why. So far, the only explanation I have is from one of the
specification's authors, saying that the set of valid characters is unclear
and might become more restricted in the future and that anyone choosing an
IDN now is gambling that their name will be made syntactically invalid later.
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.
This looks like a small matter of engineering preference, but it
is the sort of thing that introduces notable implementation variations and
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.
Any specification needs to pay attention to clarity, both for
technical accuracy and for ease of adoption by the Internet technical
community. The IDN specification effort has demonstrated a long and
difficult history, notably including widespread failure to understand the
nature and scope of the specification effort. A specification that is not
crystal clear encourages that misunderstanding.
The document does not clearly distinguish normative from
The document does not clearly distinguish implementation choice
from protocol specification. In fact, it is written almost entirely from a
programming perspective, rather than as a protocol format.
These are certain to encourage misunderstandings of the
specification. Never good for interoperability.
Dave Crocker <mailto:firstname.lastname@example.org>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850