Re: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt

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

At 06:44 PM 6/14/00 -0600, Jim Sermersheim wrote:
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/14/00 12:45:14 PM >>>
>>Additionally, I believe it might be generally useful for
>>clients to be able to distinguished duplicated entries
>>from non-duplicated entries returned by a search with
>>this control.  I suggest that a control be returned
>>in each LDAPMessage which contains a duplicated entry.
>
>Interesting, if this were done, we'd need to define exactly when this control is to be returned. For example, a search result entry is returned that _would_ have been split into duplicates if it had multi-values, but it wasn't because it happened to have a single value, does it come with a control? 

No.  Only duplicated entries would have control.

>>In particular, this would be useful where the server was
>>able to return duplicate entries for a subset of the
>>requested entries and the control was marked non-critical.
>
>If the mechanism allows for partial support,

It already does per 4.2:
   A result field is provided here to allow feedback in the case where
   the criticality of the request control is FALSE, and the server
   could not process the control - yet it could complete the search
   operation successfully.

That is, the server completed the search but failed to split all
entries as requested.

>I would think the semantics of the criticality field would change.

Actually, we should review the additional semantics of upon the
criticality flag proposed in the I-D.  Per RFC 2251:
   If the control is unrecognized or inappropriate but the criticality
   field is FALSE, the server MUST ignore the control.

I think the specification should allow partial processing based upon
the criticality flag of the control.  If such is desirable, then
a separate flag (within the control value) should be used.

>Users will probably expect that whether or not the mechanism is serviced fully or partially, it won't fail even when marked critical.

Precisely why the control value should specify whether the
server may provide partial processing.

>To allow for that, we could introduce yet another field that modifies the semantics of a critical control (call it partialAllowed).

An paritial field should modify the semantics of the control irregardless
of whether it's critical or not.  The critical flag should be used
by the server (which recongizes the control) to determine if the
specified control value (partial flag, attribute descriptions) is
appropriate or not.

>Given a critical control, if partialAllowed is TRUE, the operation will still succeed as long as the control is supported on one or more entries (even if those entries don't produce duplicates). If partialAllowed is FALSE and the control is critical, then the server must be able to apply the control to all search result entries, otherwise the entire operation fails.

Again, we should be careful not to overload the semantics of the
critical flag.