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

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

At 09:47 PM 6/14/00 -0600, Jim Sermersheim wrote:
>>>> "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?

No, because the result code might be sizeLimitExceeded after
one of many dups were returned.  (I assume this is how the
control interacts with sizeLimits... this should be specified).

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

So, the server must first run through all the entries to determine
if it able to honor the control before returning a single entry.

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

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

It MUST work as specified if recongized and appropriate.  Otherwise,
ignored if not critical or unavailableCriticalExtension if critical.

>the partialAllowed flag within the controlValue would be one of the specifiers.

Yes.