Perhaps actually differing between "short names" and actual string encoding would be prudent?
I don't think we could really go ahead and deprecate the use of "UID", as RFC 2253 defines it as the proper string encoding of the userid attribute type, and the "short names" appear to be used when string encoding distinguished names. Perhaps clearing up this ambiguity by adding a new, optional, string encoding parameter (along with macros/functions etc.) for objects would be best? //oscar Jean-Marc Desperrier wrote: > > Richard Levitte - VMS Whacker wrote: > > > From: Jean-Marc Desperrier <[EMAIL PROTECTED]> > > > > Note that since the short name UID exists in both "camps" and OpenSSL > > is somewhere in the middle, there's a definite conflict of interest > > here. However, most people I've talked with consider UID to be > > deprecated in the X.500 world, so perhaps it's not such a problem any > > more. Thoughts on this? > > The little research I've done not make me an expert on this at all, but gave me the >feeling that > not many people in the X500 world really use the UID abreviation for unique >identifier, but that > the UID abreviation for user identifier is definitively frequent. > > Deprecating the use of uid in openssl seems to me the best thing to do, changing it >to designate > user id instead of unique identifier should _not_ be done, because that would mean >that > recompiling applications with a newer version of openssl would have unexpected, >transparent > changes everywhere the string "uid" is used, in a call to OBJ_txt2nid for example. > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
