COM/NET informational message

Fri Jan 3 20:15:20 UTC 2003

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 at brics.com>
To: blacklist at 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 at brics.com>, or you are likely to
be blocked.