[thanks paf]
on 6/10/2002 1:58 AM Patrik F�ltstr�m said the following: > The problem is not capitalization. If you ask for preservation, you should > ask for preservation of the original string. Just looking at case > preservation is a very very tiny issue. Yeah, can I have preservation? Normalization will also vary. > And, caches will have issues with it, and the compression algorithm and... Some of these issues are showing up in the conversion work too, as you can imagine. They give me headaches. EG, when you change an owner name from UTF-8 to ACE, the converting system needs to find all of the compression pointers which refer to that owner name and then expand/relocate them. This can be handled through a mix of features -- compression-specific EDNS label types for one -- and this can work without the converter having intimate knowledge of the record structure (only the owner names will be converted). If I can solve that, then I have also solved one of the big problems with STD13 domain names at the same time. I am planning to minimize the risk of collisions by prohibiting sister owner names from being entered which would collapse to the same domain name. Although this isn't technically required, better safe than sorry. The rule can be relaxed later if it proves unnecessary. > So, the result was that at the end, we always to conversion of strings when > they go "into the system" of application and DNS protocols. Within that > world, that f(X) is what is used. Period. Yeah, I understand the need for it, and I support it for the common scenario. But we also need to offer this capability if we want people to not invent STD13 octet interpretations. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
