Update restrictions (Was: protocol-27 comments)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 10:31 PM 10/28/2004, Jim Sermersheim wrote:
>>> 4.7. Add Operation
>>
>>> - attributes: the list of attributes that, along with those from the
>>> RDN, make up the content of the entry being added. Clients MAY or
>>> MAY NOT include the RDN attribute in this list. Clients MUST
>>> include the 'objectClass' attribute, and values of any mandatory
>>> attributes of the listed object classes.
>>
>>If the RDN is an objectClass, does that object class need to be
>>supplied? (Not that I care if it is addressed or not, it's just a weird
>>example which occurred to me:-)
>Hmm, well as long as we're being pedantic, do all entries which can be added by a cleint require the objectClass attribute? I've seen hints that some implementations allow DSE's of certain DSE types to exist without an objectClass attribute (I think this was a justification for the T/F filter specification). It would probably be better to say that the entry being added must conform to the data model.

[Models, 7.1]
  Servers MUST ensure that entries conform to user and system
  schema rules or other data model constraints.

Echoing this for each update operation may be appropriate.


>>> Server implementations SHOULD NOT restrict where entries can be
>>> located in the Directory unless DIT structure rules are in place.
>>> Some servers allow the administrator to restrict the classes of
>>> entries which can be added to the Directory.
>>
>>Seems to me this fits better in [Models] than [Protocol]. If left in
>>[Protocol], it really applies to Modify DN and Modify too (and extended
>>operations like Modify Password), so it's a bit misplaced under Add.

While I think general-purpose Server implementations should
not place arbitrary restrictions upon entry placement (they
certainly can and should enforce administrative restrictions
upon entry placement), I think it fine for an application-specific
to place application specific restrictions upon entry placement.

As this statement is only applicable to certain classes of
server implementations, I believe the statement is more
appropriate made in an applicability statement for "general
purpose" LDAP servers (or other ASs where such a requirement
is applicable).  Hence, I think the statement should be
deleted from the LDAP TS.

>I agree, my suggestion about 'conforming to the data model' above should be generic and should apply to all update operations.