[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Dots, and a path to working IDNs
- To: "D. J. Bernstein" <djb@cr.yp.to>
- Subject: Re: [idn] Dots, and a path to working IDNs
- From: "Eric A. Hall" <ehall@ehsco.com>
- Date: Wed, 30 May 2001 12:37:31 -0700
- CC: idn@ops.ietf.org
- Delivery-date: Wed, 30 May 2001 12:38:15 -0700
- Envelope-to: idn-data@psg.com
- Organization: EHS Company
"D. J. Bernstein" wrote:
> I again ask the WG chairs to run a poll to see whether we have
> consensus that the long-term IDN solution will encode Unicode
> characters as UTF-8 on the wire.
So that we know exactly what it is that we'd be voting for or against,
could you put together a draft which clearly documents how your
just-send-utf8 proposal would work with the legacy protocol and
implementations in the following scenarios:
a) Where does bad-v-good filtering occur? For example, allowing
current apps and resolvers to just-send-utf8 means that
Z-with-caron will have different code values based on the
local charset (windows-1252 is different from 8859-15 is
different from 10646/unicode). Where and how is the
normalization handled in your scheme?
b) How do you prevent utf8 chars from breaking legacy devices?
EG, for an older (and orphaned) X terminal that legitimately
rejects underscore in hostnames, how do you keep utf8 from
jamming up bootp/tftp on that host? Similarly, how do you
prevent utf8 in CNAME responses from jamming up all of the
other hosts that legitimately enforce existing standards?
c) Also, how do you prevent utf8 in PTR RRs from jamming up
syslog daemons, received headers, netstat output and the
hundreds if not thousands of other applications that
currently process PTR data for hostnames and which reject
data that does not comply with LDH rules?
I don't think you can do it with the current protocol and implementation
limitations. Your hand-waving is unconvincing. Prove me wrong. Consider
yourself double-dog-dared if you must, but please either poop or get off
the pot. Unless you can clearly describe how this will work, please let us
get on with real progress.
I repeat, this needs to be in an ID so that we know for certain what you
really mean. Your web site does not serve that purpose.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/