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

[Dan Oscarsson <Dan.Oscarsson@trab.se>]

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