on 6/9/2002 10:33 PM Adam M. Costello said the following:
> What I'm suggesting is that whenever you apply Stringprep, you also > apply Punycode and prepend the prefix. Which is the replication master and the application. That's not a problem. > Whenever you roll out a new Stringprep profile, the things that > need to get updated to know the new profile are exactly the same things > that need to get updated to know the new prefix. Resolvers, middle-boxes and replication masters all need to be able to convert between EDNS and ACE as part of the fallback process. Distributing the profile-specific prefix to every point where conversion might occur is a massive problem. The only way it would work in your model would be for conversion to only occur at the application or at the replication master. But if the query made it to the replication master there's no reason to do conversion, so we are left with the application always performing conversion. That design blows up the architectural benefits from having the middle-boxes do it (in particular, having the caches learn the data so they can cache it). It will sometimes be necessary to have applications perform conversion but requiring it would blow up DNS. > Of course, my suggestion implies that there is no prepared-UTF-8 format, > there's unprepared-UTF-8 and prepared-ACE. I don't see the point of > using prepared-UTF-8 as an interchange format, when ACE works just as > well, requires essentially the same effort from applications, and has > the added benefit of backward compatibility. For generating names, ACE conversion is an extra step that comes after creating the structured UTF-8 domain name. Furthermore, it is an unnecessary step if the application and protocol are only using UTF-8 domain names. Meanwhile, there is nothing saved from using unstructured UTF-8 in DNS, since the applications have to use the rules anyway if they are specifically exchanging domain names. The only "extra" step is validating data which has been received, which isn't an extra step for any application with half a clue. It's a fundamental tenet of application design to validate the data you get from the network. Only an idiot would use complex strings without some kind of validation first. Besides, you would also need to do this as part of any decoding of ACE back into the canonical i18n domain name, so this extra step also applies to you (not to mention the extra step of conversion). On all counts, using structured domain names is the fastest of the safe routes, and is only step longer than the shortest route. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
