Robert Elz wrote: > > Date: Sat, 6 Apr 2002 11:55:50 +0200 (MET DST) > From: Gunnar Lindberg <lindberg@cdg.chalmers.se> > Message-ID: <200204060955.LAA09381@wilfer1.cdg.chalmers.se> > > | To me the real issue, however, seems to be in the applications, i.e. > | in the resolvers > > If applications have problems with this, they almost certainly need to > be fixed anyway - regardless of what the standards say should appear, > the application has to deal with what actually exists, which need not > have a lot in common with what is specified. There are a couple of intertwined problems here. First off, the octet values are not specified with an interpretation, so what is the application supposed to use when it has to render the values? Conversely, if the user specifies some non-ASCII characters, will these be the same characters that are displayed by the remote end-point? The problem isn't transferring the octets, it is converting the octets from display to transfer, or vice versa. In that regard, the applications which multilate eight-bit names are somewhat broken (hyper-technical perspective), but to be fair, it's not solely their fault. This is the exact same problem as IDNA transliteration -- there's no telling what happens to the data after it has been mutated for rendering, and vice versa. This is where isolation becomes important. Keep the old apps out of the new *interpreted* eight-bit namespace, using new APIs, new messages, whatever it takes. If they screw up due to an interaction problem with charsets, give them an error instead of giving them the wrong information or allowing the wrong information to pollute other apps. I agree that it would be nice if the old apps could be fixed (then we could go with 'just-use-UTF8'), but the truth of the matter is that there isn't any way to tell if an old app *HAS* been fixed, other than to use some new mechanism, as in the above. So, long story short, there's no way to just lay this on the apps. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/