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
