directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Binary attributes handling in the API
Date Mon, 06 Feb 2012 13:04:42 GMT
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