[Date Prev][Date Next] [Chronological] [Thread] [Top]

Parent objectclass ambiguity in RFC 2251



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.