Manuel Gaupp wrote: > Michael Ströder wrote: >> Please review this draft intended to be published as informational RFC. > > Section 2 ends with the following requirement: > > LDAP clients displaying a list of entries of these object classes > should use mandantory attribute 'cn' to display select lists, hyper- > links etc. > > I think this requirement is a bit too specific for such generic object > classes. In my opinion, default behavior should be to use the attribute(s) > from the RDN, any other behavior should depend on the specific use case.
I expected this text to provoke some discussion. ;-) But I'd like to encourage deployers to think of sufficiently descriptive common names stored in attribute 'cn' within a given context. Note that 'namedObject' entries are not really usable without auxiliary object class(es) which limit context and thus the meaningful name space for 'cn'. > And, think of multivalued RDNs: "cn=namedPolicyEntry+serialNumber=0815" and > "cn=namedPolicyEntry+serialNumber=4711" would both be listed as > "namedPolicyEntry" according to this requirement. I know that some people use DNs like in your example above to make DNs itself more readable. But personally I think that multi-valued RDNs really suck because you have to rename an entry in case one of the characteristic attributes change which is more effort when maintaing data. And I saw too many software components failing to handle them correctly. So one could understand the recommendation in the I-D also to discourage use of multi-valued RDNs. ;-) > Section 4 contains the following definition: > The OID arc used for the object class defintions is: iso(1) org(3) > dod(6) internet(1) private(4) enter-prise(1) stroeder.com(5427) > objectClasses(6) > This does not match the OIDs used in the object class definitions > (1.3.6.1.4.1.5427.6 versus 1.3.6.1.4.1.5427.1.389.6). Fixed. Thanks! Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
