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.