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.
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.
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.