Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms080904050007060500070608
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Kurt(a)OpenLDAP.org wrote:
> Client's really should, in general, just do their own sorting over the
> result set, especially for sorting entries for presentation purposes.
People are always asking for paged displaying of address book data sorted=
by
name. If you have large result sets that's a problem at the client's side=
=2E
But my feeling here is also ambivalent. I always tell people to narrow th=
e
search because wading through large result sets by clicking through pages=
is
not very efficient for the user himself anyway. Same problem with users
constantly asking for tree browsing. A horrible inefficient UI tool in la=
rger
deployments...
> The only case where I see this control being useful is, in conjunction =
with
> the paged results control, for asking for the entry with the lowest/hig=
hest
> single-valued serial number (or like) attributes.
For suggesting the next free unique number in an input form?
Ciao, Michael.
--------------ms080904050007060500070608
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC
BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx
MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy
IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl
cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB
BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov
L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq
hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj
/E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd
dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH
SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ
AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63
TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT
QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ
R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv
n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy
D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB
gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx
IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1
cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQyMDE2MTY1OVowIwYJKoZIhvcNAQkEMRYE
FLqReNhqM0dMvax8KwzbLzq2PziaMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq
hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n
IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG
CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6
Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh
MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE
ggEAyVNeNLp1NZXO0tamjjP+hri2OEvcaw5ik9BhpeqH8Vu88UsTd33c5Md3tdYNsXF6D9ud
V8+dFYOSU9E7CTHdfdLojAW3HsBoQYuMvJWq74SkYOoShn8DQ1rG4PGIdOW0ZiUvZTzT+sRY
UEY1Yst/iUG+N5LTaM5IMUoH/GMcgab2pWUSLkF+YkNG05XLHkg9tdIj51xCRP9Ic4kfDQos
zD+TsKM/39xyEBtMMGjBnPUxGurKIdvltS95Z1bZ15L4PApHKMWZBIfizbO8KrFUEA8YT8IQ
+grclVEKMgwybt9K2m3dQ1Vn3niIioysIJED9CVoK00ylvSkpC8fsjMtfAAAAAAAAA==
--------------ms080904050007060500070608--
10 years, 11 months
Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by clem.oudot＠gmail.com
Le 20 avril 2012 18:00, <Kurt(a)openldap.org> a écrit :
>
> On Apr 20, 2012, at 8:25 AM, kurt(a)openldap.org wrote:
>
>>> which use the sss
>>> control on standards attributes like cn or sn.
>>
>> maybe you should file a bug report with them.
>
> and I should note that I consider most client use of this control, itself, to be a bug.
Ok Kurt, I let you explain that to Microsoft and IBM ;)
By the way, I understand your arguments, I just wanted to notify the
OpenLDAP team of this problem, because that can force customers to use
another LDAP directory in order to stay compatible with such (buggy)
softwares.
Clément.
10 years, 11 months
Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org
On Apr 20, 2012, at 8:25 AM, kurt(a)openldap.org wrote:
>> which use the sss
>> control on standards attributes like cn or sn.
>
> maybe you should file a bug report with them.
and I should note that I consider most client use of this control, itself, to be a bug.
Client's really should, in general, just do their own sorting over the result set, especially for sorting entries for presentation purposes.
The only case where I see this control being useful is, in conjunction with the paged results control, for asking for the entry with the lowest/highest single-valued serial number (or like) attributes.
-- Kurt
10 years, 11 months
Re: ITS#7239: testbed
by h.b.furuseth＠usit.uio.no
We seem to be two guys discussing work we're not volunteering
to do anytime soon, but anyway...
On Fri, 20 Apr 2012 07:22:32 GMT, masarati(a)aero.polimi.it wrote:
> On 04/19/2012 11:20 PM, Hallvard Breien Furuseth wrote:
>> No, I meant the opposite: The macroization is done. It could mostly
>> be
>> scripted and makes no semantic change unless #ifdef(SlapReply
>> debug),
>> which is what the macros were for.
>
> Right.
Actually one simpler but uglier macro is enough, without
touching non-internal calls:
/*
* Do ACT with OP->o_internal set.
* Example: WITH_INTERNAL_OP( op, rc = op->o_bd->be_add( op, rs ));
*/
#define WITH_INTERNAL_OP(op, act) do { \
int *const wio_intern_ = &(op)->o_internal; \
int const wio_save_ = (*wio_intern_)++; \
act; \
(*wio_intern_)--; \
assert(*wio_intern_ == wio_save_); /* Keep this while testing
*/ \
} while (0)
Not my preference, but at least it's an option.
>> Figuring out which ops to tag as internal does, as you say, require
>> review and testing. And one extra arg to the macros.
>
> How do you suggest to proceed?
If I were doing it, I'd play in a separate branch while getting
a feel for how it'll end up. Never mind the exact API, it can
be rewritten at this stage if it's unsufficient or overkill.
Then give master whatever framework is neeed to allow the rest
of the job to be done some operation calls at the time, without
needing a monster commit to develop and review.
Technically, if not just the wrapper macro above:
> I believe using different macros, e.g.
> slap_bi_op_internal, slap_be_op_internal and SLAP_OP_INTERNAL is
> clearer
> than having an additional 0/1 parameter. OTOH, adding further
> parameters in the future would be probably easier if we extend your
> macros.
Fair enough. 0/1 could be enum constants, but that's more verbose.
And it's just 6 macros for now: My 3 old plus 3 new.
/* In proto-slap.h: */
#define slap_bi_op( bi,which,op,rs) ((&(bi)->bi_op_bind)[ which ](op,
rs))
#define slap_be_op( be,which,op,rs) slap_bi_op(
(be)->bd_info,which,op,rs)
#define SLAP_OP( which,op,rs) slap_be_op( (op)->o_bd,
which,op,rs)
/* Internal operations - as above but with op->o_internal set */
LDAP_SLAPD_F (int) (slap_bi_intop) LDAP_P(( BackendInfo *bi,
slap_operation_t which, Operation *op, SlapReply *rs ));
#define slap_be_intop(be,which,op,rs)
slap_bi_intop((be)->bd_info,which,op,rs)
#define SLAP_INTOP( which,op,rs) slap_be_intop(&(op)->o_bd,
which,op,rs)
/* In backend.c: */
int slap_bi_intop(
BackendInfo *bi,
slap_operation_t which,
Operation *op,
SlapReply *rs)
{
int rc;
WITH_INTERNAL_OP( rc = slap_bi_op( bi, which, op, rs ));
return rc;
}
> At this point, we need consensus on addressing ITS#6758 in the first
> place.
Nah. ITS#6758 needs the macros (at least if I'm to go at it),
but the macros don't need ITS#6758 since they don't change what
the code does.
Hallvard
10 years, 11 months
Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org
On Apr 20, 2012, at 7:56 AM, clem.oudot(a)gmail.com wrote:
> Le 20 avril 2012 16:22, <hyc(a)symas.com> a écrit :
>> Kurt(a)OpenLDAP.org wrote:
>>> On Apr 20, 2012, at 6:35 AM, Howard Chu wrote:
>>>
>>>> Kurt(a)OpenLDAP.org wrote:
>>>>> Incorrect behavior per the standards. If the control is recognized and
>>>> implemented, then it's to be processed regardless of the criticality. There's
>>>> not supposed to be any "if it errors, ignore it" processing.
>>>>
>>>> Thanks for the confirmation. The text of RFC2891 seems contradictory here though.
>>>
>>> RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing.
>>>
>>>> Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching).
>>>
>>> Both 3 and 4, especially when taken together, overload criticality.
>>>
>>> 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries.
>>>
>>> 4 isn't much better.
>>>
>>> So the whole specification is a mess.
>>>
>>> What I recommend is this,
>>>
>>> If the server implements the control:
>>>
>>> If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success.
>>>
>>> This, I think is consistent with RFC 2891.
>>> The client application is assured that the results are sorted in the
>>> specified key order if and only if the result code in the
>>> sortKeyResponseControl is success.
>>>
>>> clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above.
>>
>> OK. I'm going to add some comments to this effect in sssvlv.c but otherwise
>> close this ITS, works as designed.
>
> I would like just mention that this choice may be relevant from an
> RFC/standardization point of view, but will lead to incompatibility of
> OpenLDAP with some softwares like Cognos or Outlook, which use the sss
> control on standards attributes like cn or sn.
maybe you should file a bug report with them.
> May it be possible to add an option in the sssvlv overlay to ignore such errors?
I prefer not to condone non-standard behaviors by adding workarounds for them.
10 years, 11 months
Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by kurt＠OpenLDAP.org
On Apr 20, 2012, at 7:54 AM, Hallvard Breien Furuseth wrote:
>> (...)
>> So the whole specification is a mess.
>>
>> What I recommend is this,
>>
>> If the server implements the control:
>>
>> If the control is present, try to sort. If able to do so, return
>> sortResult.success. Otherwise return sortResult with sortResult !=
>> success.
>>
>> This, I think is consistent with RFC 2891.
>
> Though the new behavior may be formally compatible with both RFCs,
> it certainly breaks the expectations of one of them and must do so.
Client developers implementing/using RFC 2891 should only have one key expectation:
The client application is assured that the results are sorted in the
specified key order if and only if the result code in the
sortKeyResponseControl is success.
Clients which assume results are otherwise sorted are simply broken.
And, more generally, the client developer should not assume servers adhere to all "shoulds" and "SHOULDs" in a spec.
>
> How long has the previous behavior been in in OpenLDAP? Is it
> feasible to delay the change until RE25? Seems like a typical
> kind of change to avoid doing in the middle of a release series.
As Howard's comment imply, we implement the behavior I suggest... all he's doing is clarifying in comments the current code behaves consistently with both RFC 2891 and RFC 4510.
-- Kurt
10 years, 11 months
Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by clem.oudot＠gmail.com
Le 20 avril 2012 16:22, <hyc(a)symas.com> a écrit :
> Kurt(a)OpenLDAP.org wrote:
>> On Apr 20, 2012, at 6:35 AM, Howard Chu wrote:
>>
>>> Kurt(a)OpenLDAP.org wrote:
>>>> Incorrect behavior per the standards. If the control is recognized and
>>> implemented, then it's to be processed regardless of the criticality. There's
>>> not supposed to be any "if it errors, ignore it" processing.
>>>
>>> Thanks for the confirmation. The text of RFC2891 seems contradictory here though.
>>
>> RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing.
>>
>>> Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching).
>>
>> Both 3 and 4, especially when taken together, overload criticality.
>>
>> 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries.
>>
>> 4 isn't much better.
>>
>> So the whole specification is a mess.
>>
>> What I recommend is this,
>>
>> If the server implements the control:
>>
>> If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success.
>>
>> This, I think is consistent with RFC 2891.
>> The client application is assured that the results are sorted in the
>> specified key order if and only if the result code in the
>> sortKeyResponseControl is success.
>>
>> clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above.
>
> OK. I'm going to add some comments to this effect in sssvlv.c but otherwise
> close this ITS, works as designed.
I would like just mention that this choice may be relevant from an
RFC/standardization point of view, but will lead to incompatibility of
OpenLDAP with some softwares like Cognos or Outlook, which use the sss
control on standards attributes like cn or sn.
May it be possible to add an option in the sssvlv overlay to ignore such errors?
Clément.
10 years, 11 months
Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by h.b.furuseth＠usit.uio.no
On Fri, 20 Apr 2012 14:05:34 GMT, Kurt(a)OpenLDAP.org wrote:
> RFC 2891 was written before RFC 4510... and to some degree, IIRC, was
> the reason why the criticality processing requirements were make more
> clear in RFC 4510. Overloading criticality (or any protocol element)
> is simply a bad thing.
IIRC that was done with the understanding that some control RFCs
would have to be rewritten - but apparently nobody volunteered
to do the rewrites.
> (...)
> So the whole specification is a mess.
>
> What I recommend is this,
>
> If the server implements the control:
>
> If the control is present, try to sort. If able to do so, return
> sortResult.success. Otherwise return sortResult with sortResult !=
> success.
>
> This, I think is consistent with RFC 2891.
Though the new behavior may be formally compatible with both RFCs,
it certainly breaks the expectations of one of them and must do so.
How long has the previous behavior been in in OpenLDAP? Is it
feasible to delay the change until RE25? Seems like a typical
kind of change to avoid doing in the middle of a release series.
--
Hallvard
10 years, 11 months
Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by hyc＠symas.com
Kurt(a)OpenLDAP.org wrote:
> On Apr 20, 2012, at 6:35 AM, Howard Chu wrote:
>
>> Kurt(a)OpenLDAP.org wrote:
>>> Incorrect behavior per the standards. If the control is recognized and
>> implemented, then it's to be processed regardless of the criticality. There's
>> not supposed to be any "if it errors, ignore it" processing.
>>
>> Thanks for the confirmation. The text of RFC2891 seems contradictory here though.
>
> RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing.
>
>> Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching).
>
> Both 3 and 4, especially when taken together, overload criticality.
>
> 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries.
>
> 4 isn't much better.
>
> So the whole specification is a mess.
>
> What I recommend is this,
>
> If the server implements the control:
>
> If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success.
>
> This, I think is consistent with RFC 2891.
> The client application is assured that the results are sorted in the
> specified key order if and only if the result code in the
> sortKeyResponseControl is success.
>
> clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above.
OK. I'm going to add some comments to this effect in sssvlv.c but otherwise
close this ITS, works as designed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 11 months
Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org
On Apr 20, 2012, at 6:35 AM, Howard Chu wrote:
> Kurt(a)OpenLDAP.org wrote:
>> On Apr 20, 2012, at 5:17 AM, coudot(a)linagora.com wrote:
>>
>>> Full_Name: Clément OUDOT
>>> Version: 2.4.30
>>> OS: GNU/Linux
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (88.173.78.196)
>>>
>>>
>>> I noticed that with OpenLDAP 2.4.30, a search request with a non
>>> criticical sss control on an attribute without ordering matching rule
>>> returns an error:
>>>
>>> clement@ader:~/Programmes/openldap$ bin/ldapsearch -H
>>> ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b
>>> ou=people,ou=XXX -E sss=cn
>>> # extended LDIF
>>> #
>>> # LDAPv3
>>> # with server side sorting control
>>> #
>>>
>>> # search result
>>> search: 2
>>> result: 18 Inappropriate matching
>>> text: serverSort control: No ordering rule
>>>
>>> # numResponses: 1
>>>
>>> I think the error should only be returned if the control is critical. Else, the
>>> search results should be returned, not sorted.
>>
>> Incorrect behavior per the standards. If the control is recognized and
> implemented, then it's to be processed regardless of the criticality. There's
> not supposed to be any "if it errors, ignore it" processing.
>
> Thanks for the confirmation. The text of RFC2891 seems contradictory here though.
RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing.
> Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching).
Both 3 and 4, especially when taken together, overload criticality.
3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries.
4 isn't much better.
So the whole specification is a mess.
What I recommend is this,
If the server implements the control:
If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success.
This, I think is consistent with RFC 2891.
The client application is assured that the results are sorted in the
specified key order if and only if the result code in the
sortKeyResponseControl is success.
clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above.
>
> I remember we had this conversation about control criticality before, but don't recall the details. Does the later clarification of Criticality supersede the text of RFC2891?
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 11 months