North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: COM/NET informational message
- From: E.B. Dreger
- Date: Fri Jan 03 13:34:52 2003
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
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
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 <email@example.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 <firstname.lastname@example.org>, or you are likely to