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

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

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/14/00 7:24:20 PM >>>
>>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 that case, can't the client just infer whether it's getting duplicates back or not based on the exsistence of duplicated DN's and/or the presence of multi-valued attr's where none should be?

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

No, it may not be clear, but the intent here is that this is an "all or nothing" control. Either the control is supported across the entire set of results or it's not.

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

You mean "I *don't* think the..." right?

<snip>

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

Agreed, if the control is critical, it must work as specified. the partialAllowed flag within the controlValue would be one of the specifiers.

Jim