Subject: Re: More on DIT content rules

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 30 Oct 2003 07:49:37 -0700

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 <[email-masked]> 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" 
< [email-masked] > To: < [email-masked] > 
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 < [email-masked] > 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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 30 Oct 2003 08:47:27 -0800

At 06:49 AM 10/30/2003, Jim Sermersheim wrote:
>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.

I think some implementators take the view that their servers
have implicit DIT content rules which allow an entry to belong to any
auxiliary class but choose not to publish these rules in the subschema.
I think implementors taking this view should publish their rules
in the subschema so that clients will know which auxiliary classes
may be present in entries they update.

Kurt