Another String Representation Question

Jeff Thompson <jefft@rsa.com> Wed, 26 February 1992 19:37 UTC

Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa21722; 26 Feb 92 14:37 EST
Received: from bells.cs.ucl.ac.uk by NRI.NRI.Reston.VA.US id aa21716; 26 Feb 92 14:37 EST
Received: from CHIRALITY.RSA.COM by bells.cs.ucl.ac.uk with Internet SMTP id <g.14239-0@bells.cs.ucl.ac.uk>; Wed, 26 Feb 1992 18:48:16 +0000
Received: by RSA.COM id AA00250; Wed, 26 Feb 92 10:48:59 PST
Date: Wed, 26 Feb 1992 10:48:59 -0800
From: Jeff Thompson <jefft@rsa.com>
Message-Id: <9202261848.AA00250@RSA.COM>
To: osi-ds@cs.ucl.ac.uk
Subject: Another String Representation Question

In our interoperability testing, we have already encountered
organizations which always use T.61 to represent name attribute values
for their employees. This is so that they do not have to scan values
to see if they have non-printable-string characters, like '&' in
"Sales & Marketing", which would require T.61.

If I get a business card from someone at Gadgets, such as <CN=Joe,
O=Gadgets, C=US> where "Joe" in the directory is really encoded with
T.61, how can I be sure that my software will be able to find his
distinguished name?  The directory lookup protocol says to ignore
case, but does it say to ignore T.61 vs. printable string?