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

RE: [idn] host name vs. domain name



Hi folks,

A very similar question was raised on the IETF SNMPv3 WG
list recently over the change of MIB-II System group string
objects from 'DisplayString' (NVT-ASCII) to the SNMPv3 type
'SnmpAdminString' (UTF-8).  Numerous people tried it with
various SNMP browser and manager tools (querying an SNMP
Agent that had valid UTF-8 in the 'sysDescr' string).

The results were all over the map, but all bad - dots
or spaces instead of unrecognized 'characters', hex dumps,
characters from the client's local 8-bit charset mapped
into the successive octets of the UTF-8 characters, etc.

Shifting to UTF-8 (the stated IETF policy in RFCC 2277)
in character strings throughout Internet protocols is
certainly the right way to go.  But the road there isn't
painless.

Cheers,
- Ira McDonald (consulting architect at Sharp Labs America)
  High North Inc

-----Original Message-----
From: Carl S. Gutekunst [mailto:carl.gutekunst@eng.sun.com]
Sent: Tuesday, March 14, 2000 12:28 PM
To: David R. Conrad
Cc: idn@ops.ietf.org
Subject: Re: [idn] host name vs. domain name


> Does anyone have actual empirical data for the implications to the
existing
> software which expects "host name" subset US-ASCII should that software be
> presented with UTF-8?

I mentioned this once before: as an experiment I sent myself an E-mail
message
that contained raw unencoded UTF-8 in the domain part of a route-addr. I
used
Sendmail 8.9.3 and UofW imapd 4.5, and verified that the bits were stored
and
retrieved correctly. Then I tried to display the message using Netscape
Communicator 4.7, using IMAP. Communicator core dumped.

Not a representative sample, of course, but I suspect it's not atypical. I'd
encourage other people to try the same thing with their favorite clients.

<csg>