directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: Binary attributes handling in the API
Date Mon, 06 Feb 2012 15:11:10 GMT
I believe we need this list only in the case where no schema is loaded on the connection, right?

Or, do you want to also use this list in addition to an already loaded schema?

Regards,
Pierre-Arnaud

On 6 févr. 2012, at 14:04, Emmanuel Lecharny wrote:

> Hi guys,
> 
> last week, we have had issues on Studio while using the API to load JpegPhoto attributes.
As the JpegPhoto was not known to be a Binary value, it was converted to a String, leading
to some internal transformation of the data. Not good.
> 
> So we discussed about adding a list of known binary attributes in the API, plus the possibility
to add some more if the suer is using an extended schema.
> 
> The problem here is that converting a value to a string is done during the decoding,
and we use the AT's synatax for that : if it's human-readable, then we transform the attribute
to a String otherwise it's kept as binary.
> 
> We use a list of binary syntax, which should contain the following syntaxes :
> ( 1.3.6.1.1.15.1 DESC 'X.509 Certificate Exact Assertion' ) -> CertificateExactAssertion
> ( 1.3.6.1.1.15.2 DESC 'X.509 Certificate Assertion' ) -> CertificateAssertion
> ( 1.3.6.1.1.15.3 DESC 'X.509 Certificate Pair Exact Assertion' ) -> CertificatePairExactAssertion
> ( 1.3.6.1.1.15.4 DESC 'X.509 Certificate Pair Assertion' ) -> CertificatePairAssertion
> ( 1.3.6.1.1.15.5 DESC 'X.509 Certificate List Exact Assertion' ) -> CertificateListExactAssertion
> ( 1.3.6.1.1.15.6 DESC 'X.509 Certificate List Assertion' ) -> CertificateListAssertion
> ( 1.3.6.1.1.15.7 DESC 'X.509 Algorithm Identifier' ) -> AlgorithmIdentifier
> ( 1.3.6.1.1.16.1 DESC 'a syntax for UUID values'  X-SCHEMA 'apache' X-IS-HUMAN-READABLE
'false' ) --> UUID ???
> ( 1.3.6.1.4.1.1466.115.121.1.4  X-SCHEMA 'system' X-IS-HUMAN-READABLE 'false' ) ->
Audio
> ( 1.3.6.1.4.1.1466.115.121.1.5  X-SCHEMA 'system' X-IS-HUMAN-READABLE 'false' ) ->
Binary
> ( 1.3.6.1.4.1.1466.115.121.1.8  X-SCHEMA 'system' X-IS-HUMAN-READABLE 'false' ) ->
Certificate
> ( 1.3.6.1.4.1.1466.115.121.1.9  X-SCHEMA 'system' X-IS-HUMAN-READABLE 'false' ) ->
CertificateList
> ( 1.3.6.1.4.1.1466.115.121.1.10  X-SCHEMA 'system' X-IS-HUMAN-READABLE 'false' ) ->
CertificatePair
> ( 1.3.6.1.4.1.1466.115.121.1.23  X-SCHEMA 'system' X-IS-HUMAN-READABLE 'false' ) ->
Fax
> ( 1.3.6.1.4.1.1466.115.121.1.28  X-SCHEMA 'system' X-IS-HUMAN-READABLE 'false' ) ->
JPEG
> ( 1.3.6.1.4.1.1466.115.121.1.40  X-SCHEMA 'system' X-IS-HUMAN-READABLE 'false' ) ->
OctetString
> ( 1.3.6.1.4.1.1466.115.121.1.49  X-SCHEMA 'system' X-IS-HUMAN-READABLE 'false' ) ->
SupportedAlgorithm
> 
> It's definitively a better approach than the one proposed by JNDI where we have a list
of binary Attributes (which is restrictive, as AT extending a binary AT won't be considered
as binary unless one modify this list).
> 
> I would suggest to expose this list of binary Syntax in the API, so that it can be extended.
> 
> There is one more issue we have to deal with : Attribute having a ';binary' option are
also binary AT. We have to take care of this case.
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
> 


Mime
View raw message