Subject: Models: Schema references to undefined entities

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 31 Jan 2003 20:58:57 +0100

In [Models], please specify whether the various schema elements
may refer to OIDs of entities that are not defined in the schema.
E.g. an objectclass with "MAY (<oid of undefined attribute>)", an
attribute type with an undefined syntax, a DIT content rule with
an undefined objectclass in the "AUX" part, etc.

Such undefined entities wouldn't be useful for anything in the
directory, but it could be useful to allow them in the schema
because a schema element could be defined without defining
everything it depends on.  For example, an attribute type defined
by the server's standard setup may have to be omitted because of 
a name conflict with a locally defined attribute type.  One could
edit the attribute out of the object class which uses it as well,
but that's uglier since clients would receive an incorrect
definition of that object class.

-- 
Hallvard

---

From: Michael Ströder <[email-masked]>
Date: Fri, 31 Jan 2003 22:24:47 +0100

> may refer to OIDs of entities that are not defined in the schema.

Yes, this has to defined more clearly.

> an undefined objectclass in the "AUX" part, etc.

Once I had a lengthy discussion with Kurt about some attribute types 
referencing missing syntax OIDs. We did not reach consensus about semantics. 
Kurt's claim was that e.g. a LDAP syntax can be 'partially supported' and 
hence not be listed in the sub schema sub entry.

> everything it depends on. 

At least with LDAP syntaxes this seems to be common practice today. :-/

> For example, an attribute type defined

If the object class references the attribute type by name isn't there still 
a naming conflict? IMHO the 'locally defined attribute type' gets referenced 
thus changing the object class definition. Maybe it's me but this sounds 
rather strange to me.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 31 Jan 2003 16:43:31 -0800

>Yes, this has to defined more clearly.

I don't believe there are any integrity requirements here.
If fact, there are cases where a server may not know some
schema descriptions (or choose not to publish some) even
though they are referenced by other schema descriptions.

Note that I use the term "published" here.  Schema is "defined"
in technical specifications, servers publish descriptions they
know (if they so choose).

Some servers may support schema modification, however this
is beyond the scope of this document.  (I believe there are/were
individual submissions in this area.)

>Once I had a lengthy discussion with Kurt about some attribute types referencing missing syntax OIDs. We did not reach consensus about semantics. 

The WG, I believe, reached consensus that servers publish what
they know (if they so choose) and that publication of a particular
description is not indication that the server has implemented
the semantics associated with that described element.

That is, publishing 'alias' does not imply the server supports aliases.

The current I-D reflects this.

>Kurt's claim was that e.g. a LDAP syntax can be 'partially supported' and hence not be listed in the sub schema sub entry.

Yes.  For example, a server might be able to generate values of
a particular syntax but not be capable of accepting values of
that syntax.

>>by the server's standard setup may have to be omitted because of a name conflict with a locally defined attribute type.  One could
>If the object class references the attribute type by name isn't there still a naming conflict? IMHO the 'locally defined attribute type' gets referenced thus changing the object class definition. Maybe it's me but this sounds rather strange to me.