Robert Elz wrote:
Date: Sat, 6 Apr 2002 11:55:50 +0200 (MET DST)
From: Gunnar Lindberg <lindberg(_at_)cdg(_dot_)chalmers(_dot_)se>
Message-ID:
<200204060955(_dot_)LAA09381(_at_)wilfer1(_dot_)cdg(_dot_)chalmers(_dot_)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/