SMB> Date: Fri, 03 Jan 2003 14:41:45 -0500 SMB> From: Steven M. Bellovin SMB> I'm sorry, but this is incorrect in many different dimensions. The SMB> subject was discussed exhaustively in the IETF's IDN working group; I SMB> refer you to its archive for detailed discussions. Among many other SMB> things, your assertion about the simplicity of name comparisons is SMB> wrong; see draft-hoffman-stringprep-07.txt for a discussion of that Will check these. SMB> issue. As for 8-bit clean DNS -- well, apart from the many possible SMB> ways to encode things, there's the issue of the many applications that SMB> aren't 8-bit clean, including (per the RFC 822 spec) SMTP. If "just Good point. SMB> use 8-bit clean DNS" were sufficient, we'd have been there several SMB> years ago. See http://www.ietf.org/html.charters/idn-charter.html SMB> for many more pointers. So, if I understand correctly: * RFC 2045/2047 for MIME-aware apps (SMTP, etc.) * UTF-8 for SNMP * IDNA for DNS and the FQHN part of a HTTP request? Yuck. Oh well. I guess this is just another encoding to implement. It would be a shame to try using the same encoding for everything... I'll check out the IDNA spec. Hopefully it at least encodes extended characters in a manner that strcasecmp() works without modification, i.e., upper- and lowercase chars are mapped to 'A' through 'Z' and 'a'-'z'... 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.