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

>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, I would think the semantics of the criticality field would change. Users will probably expect that whether or not the mechanism is serviced fully or partially, it won't fail even when marked critical. To allow for that, we could introduce yet another field that modifies the semantics of a critical control (call it partialAllowed). 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.

I'll wait for your feedback before diving into this one.

>Oh, and another implementation note, servers which
>chain requests should avoid passing this control to
>other servers by splitting chained results itself.

OK.

Jim