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?
- Another String Representation Question Jeff Thompson
- Re: Another String Representation Question Steve Hardcastle-Kille