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

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 14 Jun 2000 21:47:16 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 14 Jun 2000 21:22:45 -0700

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

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

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

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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 15 Jun 2000 00:06:53 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 6/14/00 10:22:45 PM >>>
<snip>
>control interacts with sizeLimits... this should be specified).

Bah... fine.

<snip>
>if it able to honor the control before returning a single entry.

Before you introduced the notion of the control being able to handle partial support, the thought was that the server can either support the control or not. The scenario above (timeLimit or sizeLimit exceeded) does present a problem though. I'm going to add the partial support stuff, so this discussion is moot now.

<snip>
agreed

Thanks.

Jim