[Date Prev][Date Next]
Re: Models: Schema references to undefined entities
- To: Michael Ströder <email@example.com>
- Subject: Re: Models: Schema references to undefined entities
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Date: Fri, 31 Jan 2003 16:43:31 -0800
- Cc: ietf-ldapbis@OpenLDAP.org
- In-reply-to: <3E3AE99F.firstname.lastname@example.org>
- References: <HBF.email@example.com> <HBF.firstname.lastname@example.org>
At 01:24 PM 1/31/2003, Michael Ströder wrote:
>Hallvard B Furuseth wrote:
>>In [Models], please specify whether the various schema elements
>>may refer to OIDs of entities that are not defined in the schema.
>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.)
>>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.
>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
>>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.
>At least with LDAP syntaxes this seems to be common practice today. :-/
>>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.
>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.