Subject: Re: Models: DIT Content Rules and AUX object classes

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 12 Feb 2003 23:02:20 +0100

Kurt D. Zeilenga writes:
>> If so, I suggest it is added that e.g. "AUX 1.1" can be used to say
>> 'no auxiliary objectclasses are allowed'.
> 
> That would be an extension to the existing schema model
> and hence beyond scope of this document.

Well, I only wanted that if 'no AUX' meant 'all aux classes allowed'.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Feb 2003 07:45:56 -0800

>Well, I only wanted that if 'no AUX' meant 'all aux classes allowed'.

In re-examining this issue, I think it might be appropriate
to add to Section 2.4.3.

   The DIT content rule associated with the structural object
   class of the entry controls which auxiliary classes the
   entry may belong to.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Feb 2003 10:34:06 -0800

In chatting with Hallvard offline about which auxiliary classes
are allowed in an entry when there is no DIT content rule associated
with the structural object class of an entry, I find that
additional clarification is needed in this area.  Hence, I suggest
replacing Section 2.4.3 (Auxiliary Object Classes) with:

  Auxiliary object classes are used augment the characteristics of
  entries.  They are commonly used to augment the sets of attributes
  required and allowed attributes to be present in an entry.  They
  can be used to describe entries or classes of entries.

  Auxiliary object classes cannot subclass structural object classes.
     
  An entry can belong to any subset of the set of auxiliary object
  classes allowed by the DIT content rule associated with structural
  object class of the entry.  If no DIT content rule is associated 
  with the structural object class of the entry, the entry cannot
  belong to any auxiliary object class.

  The set of auxiliary object classes which an entry belongs to can 
  change over time.

This, I believe, is fully consistent with X.501(93) which all
LDAP servers MUST act in accordance with.

I note that I, in general, view discussions of what servers
which don't act in accordance with X.500 beyond the scope of
the document.  If a service doesn't implement DIT content rules,
it can take any approach which is consistent with the
models.  They could either disallow auxiliary classes, they
could could allow auxiliary classes (as if they had content
rules which allowed all auxiliary classes for all structural
object classes, or take some other approach.  (As I noted in
another thread, how do lightly act in accordance with X.500
might make a good Informational RFC.)

Kurt