directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrique Rodriguez <>
Subject Re: LDAP Controls
Date Wed, 02 Mar 2005 17:28:21 GMT
David Boreham wrote:
>> to rewrite it.  I hope we keep our focus and make sure for the sake of 
>> easily adding controls we make the decoder encoder pair extensible for 
>> the variable payloads of Controls.
> I think you're imagining this to be more than it needs to be.
> Instead just punt the encoding/decoding
> of controls to the code that uses them. If I add a whizbang-special control
> that is used in my whizbang-special custom back-end, then I need to write
> code to encode and decode that control. Just make the raw BER control
> payload available to my code and I'm happy. So in the request message
> parser, when you see controls, only parse them down to a collection of
> OIDs and payload BER. Similarly when encoding a response message,
> take a collection of OIDs and payload BER that may have already been
> placed in the controls collection during operation processing.
> Of course encoder/decoders
> for common controls can be supplied in canned form, that's fine too.
> I think where you're headed is a science project : much easier to just
> say that if you use a control, then you have responsibility for its 
> encoding
> and leave it at that.

This sounds like the same problem Kerberos has, but instead of controls 
Kerberos has encrypted data payload (a DER octet string) which needs to 
be decrypted into raw DER and decoded again.  The choice of the key used 
in decryption needs to be made in the handler, so that's where the 
crypto takes place and I have to maintain my own canned encoder/decoder 
pairs.  So, I don't expect the Apache ASN.1 library to handle this for 
me; one-shot stateless codecs makes sense here.


View raw message