Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt

From: Erik Nordmark <[email-masked]>
Date: Fri, 24 May 2002 10:46:12 +0200 (CEST)

I've asked the IESG secretariat to start one IETF-wide last call on
stringprep (by itself) and one IETF-wide last call on the set of
idna+nameprep+punycode. 

   Erik

---

From: Dan Oscarsson <[email-masked]>
Date: Thu, 30 May 2002 15:06:58 +0200

vint cerf wrote

>
>what has been the practice in implementations of the various
>referenced RFCs? John's interpretation or Robert's?
>
>or has the apparent ambiguity also shown up in working
>implementations?

I know several DNS servers using non-ASCII domain names.
The Microsoft DNS servers uses UTF-8 encoded domain names
and the .NU-domain supports UTF-8, ISO 8859-1 and others
depending on what client uses.
I am sure there are more.

Using UTF-8 or ISO 8859-1 is fully compatible with the current
ASCII names as well as ISO 10646 code value compatible.

Due to the current DNS RFCs not defining how characters should
be encoded outside the ASCII range, people have selected the
best choice for their needs as seen above. It would have been
very good if the current DNS standard was updated with a RFC
stating which encoding(s) is to be used. UTF-8 or UTF-8 and ISO 8859-1
are the best choices folloging that UCS is the most common choice
for internationalisation.

    Dan

---

From: Dan Oscarsson <[email-masked]>
Date: Fri, 31 May 2002 08:15:17 +0200

Eric A. Hall wrote:

>> It is simple to standardise it. We just publish a short RFC
>> defining how octet values with the 8th bit should be handled.
>> 
>The reason why this won't work is that there is no way to determine if the
>remote end-point is compliant with the updated specification. If you want
>to enforce an interpretation of the eight-bit range, you have to use new
>RRs, a new class, an EDNS identifier, or something, in order to
>distinguish between the legacy and modern systems. Otherwise, you send
>UTF-8 to the remote system, it treats the data as MacRoman, and the
>subsequent usages are working with invalid data. There must be an
>identifier of some kind.

Why is it that IETF can change the definition on for example what
characters are allowed in host names whitout an identifer of some kind,
but cannot define how to handle undefined parts of a protocol?

All programs created following original RFCs break when it later is
changed. For example, the URI definition have changed making those
applications following the original specification reject what
later revisions see as valid URIs. From the areas I am interested
in it looks like it is OK to change an existing specification
as long as you work with ASCII characters, but when moving to
non-ASCII characters you either have to create something new or
add tags/identifiers. I do not understand why people are so afraid of
allowing non-ASCII without complex handling. I have used non-ASCII
in several IETF proticols for many years without problem even though
the standards are very unclear on how to use them.

   Dan