[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Parent objectclass ambiguity in RFC 2251
Andy
The first position expoused by yourself below is, in my opinion, the most
sensible rewording of the LDAP text. It has a double benefit of a) ensuring
server consistency with the X.500 model, and b) simplifying schema
management in LDAP clients. It does of course require that the LDAP servers
to be fully pre-configured with the all the object class definitions, but this must
be a given anyway or how else could they check the MUST and MAY contain
attributes?
David
Date forwarded: Thu, 16 Jul 1998 09:08:08 -0700 (PDT)
From: Andy Coulbeck <a.coulbeck@isode.com>
To: Mark Wahl <m.wahl@critical-angle.com>,
"Howes@Netscape. Com" <howes@netscape.com>, Steve Kille <s.kille@isode.com>
Copies to: ietf-ldapext <ietf-ldapext@netscape.com>
Subject: Parent objectclass ambiguity in RFC 2251
Date sent: Thu, 16 Jul 1998 11:12:40 -0500
Forwarded by: ietf-ldapext@netscape.com
> We have encountered an ambiguity in RFC 2251 concerning the behavior
> of an LDAPv3 server when it receives an Add (or Modify) in which the
> object class value does not include all the superclasses. This is the
> relevant text which has led to two different interpretations because of
> the use of the word "implicitly":
>
> 3.2.1. Attributes of Entries
>
> "When creating an entry or adding an objectClass value to an entry,
> all superclasses of the named classes are implicitly added as well if not
> already present, and the client must supply values for any mandatory
> attributes of new superclasses."
>
>
> Clearer wording for the different positions might be:
>
> 1) "When creating an entry or adding an objectClass value, all
> superclasses
> of the named classes are explicitly added as objectClass values,
> unless
> already present. ..."
>
> 2) "When creating an entry or adding an objectClass value, if the
> superclasses of the named classes are not explicitly present, they are not
> added as values. However, when performing schema checking, they are
> treated as being implicitly present, and the user must supply values for
> any attributes which are mandatory for these implied object classes."
>
> I would like confirmation that the first position was the one intended by
> the authors.
>
> Note the complication of the second position: the requirement is that the
> values assumed for objectClass are different for presentation and schema
> checking. Our guess is that if the intention of the authors lay closer to
> the second position, they would not have used the word "added".
>
> The LDAP specs. do make clear that the underlying data model is X.500.
> Therefore, if there is ambiguity in the specs. an interpretation which is
> closer to X.500 is to be preferred. This interpretation of the paragraph
> means that the LDAP server performs the service to the DUA of filling in
> all required superclasses. Therefore the DUA requires less knowledge of
> the schema, which is consistent with the 'L' in LDAP.
>
> Adopting the second position would complicate matters for X.500, as,
> presumably, you SHOULD fill in the superclasses when reading the entry
> over DAP.
>
> Andy Coulbeck
> Isode Inc.
>
>
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 370 957 287
Email D.W.Chadwick@iti.salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
***************************************************