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.
Erik,
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
more explicitly.
>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.
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
NOT WORK.
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
interoperability problems.
>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
non-normative text.
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.
d/
----------
Dave Crocker <mailto:[EMAIL PROTECTED]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850
