BV> Date: Fri, 3 Jan 2003 12:49:06 -0500 BV> From: "Verd, Brad" [ At the risk of going OT... ] BV> Before IDNA, some application developers had developed BV> proprietary mechanisms designed to support IDNs. The Internet UTF-8 is a standard. MS products have used two-octet chars to support Unicode for a long time. Any reason to add yet another encoding? BV> The A record that will be returned by VGRS points to a farm BV> of web servers that will attempt to resolve the query. Going to proxy SMTP as well? BV> If a user downloads and installs the i-Nav plug-in, his or BV> her browser will convert any IDNs entered to ASCII compatible BV> encoding (ACE) format, according to the method described in BV> IDNA. As a result, subsequent DNS queries will use ASCII BV> characters only. Why? Programmers already are (or should be) supporting UTF-8. Searching RFC1035 for "binary" indicates a nameserver should be able to handle chars >= 0x80. All that's left is deciding on an encoding and handling case. BV> The web servers refuse connections on all other UDP and TCP BV> ports, so other network services are minimally affected. Uhhhh.... more like the ugly kludge only addresses HTTP, and other network services just won't work. BV> The overriding goal is to improve Internet navigation by BV> encouraging widespread adoption of software supporting the BV> emerging IETF standards for IDNs. These measures allow BV> distribution of such software. How about encouraging widespread adoption of EXISTING standards instead of adding more cruft? UTF-8 is standard. Proper DNS implementations are eight-bit safe. People upgraded browsers due to SSL, Year 2000, Javascript... Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.