Hey Michael,
Your draft (draft-stroeder-namedobject-01) basically defines a common,
structural object class to be combined with arbitrary auxiliary classes
established e.g. in other standards.
This could drastically reduce the number of structural ('non-combinable')
object classes defined for public use. This in turn might reduce the number
of custom classes to combine several structural classes from public schema
definitions.
I did not yet find any satisfactory rationale for specifying the kind of a
class within the object class definition anyways. IMHO, the structural
object class of an entry - if required at all - should be defined during
instantiation of that particular entry and may be governed by structure
rules.
Since LDAPv3 is the current and proposed standard, I think your proposal is
the best approach we have regarding that issue.
As attribute 'cn' is multi-valued and ambiguous entry names in
user-interfaces are pretty annoying, I would like to restrict your
recommendation on string-representation of entries in chapter 2 as well.
<proposal >
In case that any value of mandatory attribute 'cn' is used to form the RDN
of an entry of these object classes, LDAP-clients SHOULD use that
distinguished value for string-representation of the particular entry (e.g.
within user interfaces). Any additional AVAs present in such a RDN SHOULD
also be included in the entries string-representation, indicating the
attribute type of each additional value.
</proposal>
As this recommendation is pretty generic, it might fit in more smoothly
into a more generic LDAP client BCP. :o)
Regarding to your rationale for class 'namedPolicy' in chapter 2.2:
I dont understand how combining policy-related auxiliary classes with class
'namedObject' would restrict this class in any way.
Regards, Linus
