Re: Update restrictions (Was: protocol-27 comments)

["Jim Sermersheim" <jimse@novell.com>]

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 11/3/04 6:30:16 PM >>>
>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.

Unless others respond, I'll assume that consensus is to remove "Clients
MUST include the 'objectClass' attribute, and values of any mandatory
attributes of the listed object classes." and add the text from [Models]
7.1 to all update operations.

>>>> 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.

Unless others respond to this, I will assume this is consensus and
remove the paragraph (unless it turns out I cannot add the [Models] 7.1
text to each update operation).

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