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

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 03 Nov 2004 15:30:16 -0800

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.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 7 Nov 2004 22:18:56 +0100

Kurt D. Zeilenga writes:
>>> I wonder if the PartialAttribute [in ModifyRequest] should be
>>> OPTIONAL in the grammar and instead "REQUIRED unless otherwise
>>> specified" in the text, anticipating new ModifyRequest operation
>>> types (per [LDAPIANA]) that need a different data structure than
>>> PartialAttribute.
> (...)
> While I believe it unlikely that WG consensus would
> support making the modification component OPTIONAL, I
> will defer declaring consensus for a bit to allow
> on list discussion.  Those who support making this
> change should offer compelling reasons why it should
> be made.

For the record, since I brought it up: I have no preference on the
subject.  However, note my message 'Cross-purpose SEQUENCE/CHOICE
protocol extension fields'.

-- 
Hallvard