Re: (ITS#5785) dontUseCopy in slapd requires criticality to be TRUE

[ando@sys-net.it]

michael@stroeder.com wrote:
> ando@sys-net.it wrote:
>> The "dontUseCopy" control requires criticality to be TRUE.  While this is the
>> desirable value,
> 
> Why is this a desirable value? The answer Kurt gave on ldap-ext mailing
> list just mentioned direct mapping to X.511 dontUseCopy option.

Because.  If you need to avoid using copy, then you strongly need it. 
If it's just a wish, then don't use it, assuming the DSA you contact 
will do no more than what it can to provide you valid data.  You would 
otherwise be misuing the control.

>> a DUA could use the control with the criticality set to FALSE.

Yes, perfectly legitimate (from a DSA's point of view, as per RFC4511) 
but contrary to the control's specification (and, IMHO, to common sense).

> As I stated on ldap-ext mailing list in this case I'd simply accept a
> best effort on the DSA side.

IMHO you already get the best effort by not using the control.

> So sending "dontUseCopy" control with
> criticality FALSE would mean: If the DSA supports this control it should
> *process* it according to what's specified in
> draft-zeilenga-ldap-dontusecopy. Otherwise ignore it.

No.  The spec looks broken to me, because it contradicts RFC4511 (from 
the DSA's point of view).  The DUA must use TRUE to comply with 
dontUseCopy.  If it doesn't, then the DSA can do its best to honor it, 
but nothing more.  If the DSA finds out it can chain a request, but this 
would cost resources, it could return a referral, or simply ignore the 
control.  All of these behaviors would comply with criticality to FALSE.

> The main problem is that a DUA cannot determine in advance whether a DSA
> supports a certain control for a certain backend. It turned out in
> practice that looking a supportedControl in rootDSE does not have any
> meaning at all.

You got a clear answer: the only ultimate way to know is to try.  If you 
use FALSE, you'll never know.

> IMO yet another control does not solve this.

It does: you add dontUseCopy with criticality set to TRUE; you add the 
whatFailed control; if dontUseCopy fails, you'd know for sure.  Then you 
don't need to use it any more, as using it with FALSE would make no sense.

>> For full conformance with RFC4511, if the control is syntactically well-formed
>> and criticality is set to FALSE, slapd MUST accept it if recognized, or MUST
>> ignore it if not recognized, but CANNOT question the fact that the value of
>> criticality is violating the control's specification.
> 
> I'm not sure whether this statement can be made generally. I'd wish so
> and I'd rephrase "accept it" to "process it".

With "accept" I mean: "recognize it"; with "process" I'd mean "apply it 
to the operation".  If you set criticality to FALSE and the DSA does not 
recognize it, the DSA will just ignore it.  If the DSA recognizes it, it 
is at the DSA's discretion to either apply it or not, based on what the 
DSA considers best (including interoperability with the specific 
operation, with other extensions, with resource consumption and any 
other consideration about the opportunity to process it).  I'm pretty 
sure you agree that elaving so much discretion to the DSA about 
something related to data integrity does not differ too much from not 
using the control at all.

p.