[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] Dots, and a path to working IDNs




"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/