|
While the idealist in me says this is a good direction, the
realist is quivering in fear of the lynch mob of customers that would ensue as a
result of implementing this restriction.
Currently, NDS allows any attribute name to be used in a DN as
long as it's defined in the schema and is a valid naming attribute for the
object class. This name is also returned in the DN (as opposed to an OID). I
suspect that many other vendors behave this way as well.
Can you go into more detail as to why allowing any attribute
name in a DN is a bad thing?
Jim
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 11/1/00 1:46:02 PM >>> At 11:35 AM 11/1/00 -0700, Jim Sermersheim wrote: >I like the removal of the "example" language, but this also stops any future attribute name from being used. >If, for example, I have an attribute called SSN and I want to use it as a naming attribute, there is no way for me to get it into the table so that people don't have to use its OID form in string representations of DNs. Given the problems associated with depending BER DN-> LDAP DN string generation upon the controlling schema or other DSA-specific (or shared) information, restricting the use of attributes names to those in "a published table" is sound and should not be changed. Given that this table likely needs to be embedded in implementations, a static table is a very good thing. If a implementation where to use a different table than another implementation, I believe significant interoperability problems would arise. Kurt |