[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: object class values in a read or search result
Keutel, Jochen (mlists) wrote:
Hello,
> Also as a general rule the X.500 data model requires that a server store
and return exactly what the user provided.
please tell me where in X.500 you find this. I couldn't find it. Instead I
found (X.501 (2008), chapter 13.3.2 (" The object class attribute") :
"Every entry shall contain an attribute of type objectClass to identify the
object classes and superclasses to which the entry belongs. The definition of
this attribute is given in 13.4.8. This attribute is multi-valued.
There shall be one value of the objectClass attribute for the entry's
structural object class and a value for each of its superclasses. top may be
omitted."
This means - in my understanding - that the server has to set these values for
the attribute object class - one per superclass.
Please, this is an ancient question, answered long ago.
http://www.openldap.org/lists/openldap-software/200208/msg00721.html
Search the archives. There's no point carrying this one on again.
Am 22.03.2013 21:02, schrieb Howard Chu:
Michael Ströder wrote:
Manuel Gaupp wrote:
I don't think so, because RFC 4512, section 3.3 says:
"When creating an entry or adding an 'objectClass' value to an entry,
all superclasses of the named classes SHALL be implicitly added as
well if not already present. [...]"
If I'm interpreting this correctly, the OpenLDAP behaviour is a bug.
Well, "implicitly added" is a bit vague to call it a bug since the entries are
returned when searching for the superior object class.
In the sense that "implicit" is the opposite of "explicit" the OpenLDAP
behavior is exactly correct. Also as a general rule the X.500 data model
requires that a server store and return exactly what the user provided.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/