|
Maybe I'm strange, but I like it. It allows server implementations to use this mechanism to control and advertise things such as which objects to expect what operational attributes to be available.
I don't doubt that as things progress, some implementations will auto-add certain DIT content rules to certain types of object classes when they are added. As well as perhaps invent other mechanisms that make the addition of aux classes more seamless than it would seem on the surface.
Jim
>>> John McMeeking <jmcmeek@us.ibm.com> 10/30/03 6:17:54 AM >>> I think the equivalent statements from X.501 are: ---------- If no DIT content rule is present for a structural object class, then entries of that class shall contain only the attributes permitted by the structural object class definition. An entry governed by a DIT content rule may, in addition to the structural object class of the DIT structure rule, be associated with a subset of the auxiliary object classes identified by the DIT content rule. This association is reflected in the entrys objectClass attribute. ---------- That does seem to say that if there is no DIT content rule, the entry cannot belong to any auxiliary object classes. And it does seem strange to me. John McMeeking "Jim Sermersheim" < jimse@novell.com > To: < ietf-ldapbis@OpenLDAP.org > Sent by: cc: owner-ietf-ldapbis@O Subject: Re: More on DIT content rules penLDAP.org 10/29/2003 07:54 PM Actually, what's being documented here has always been true. Most of the text is being pulled in part or whole (summarized or not) from X.501. Previously, one had to find these statements by reading hte ITU documents. Jim >>> Michael Ströder < michael@stroeder.com > 10/29/03 10:34:10 AM >>> HI! Still browsing through draft-ietf-ldapbis-models-09... In section 2.4.3 there's written: [..] If no DIT content rule is associated with the structural object class of the entry, the entry cannot belong to any auxiliary object class. I don't understand this statement. Shouldn't the 'cannot' be 'can'? From section 4.1.6.: MUST, MAY, and NOT specify lists of attribute types which are required, allowed, or precluded, respectively, from appearing in entries subject to this DIT content rule; and <extensions> describe extensions. I'm a little bit scared of 'MUST' and 'MAY' extending the 'MUST' and 'MAY' of object classes. I consider this being redundant to schema design with object classes. Personally I'd appreciate a hint in the text stating that use of 'MUST' and 'MAY' in a DIT content rules is NOT RECOMMENDED since clients or servers might not support DIT content rules. Well, such a hint might be a little too much in the direction of a best practice guide. Ciao, Michael. |