You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2012/02/06 14:04:42 UTC
Binary attributes handling in the API
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
Re: Binary attributes handling in the API
Posted by Alex Karasulu <ak...@apache.org>.
On Mon, Feb 6, 2012 at 5:58 PM, Emmanuel Lécharny <el...@apache.org>wrote:
> On 2/6/12 4:11 PM, Pierre-Arnaud Marcelot wrote:
>
>> I believe we need this list only in the case where no schema is loaded on
>> the connection, right?
>>
>
> Sadly, no. For servers that don't expose the information about the non
> human readable Syntax, we have to provide it. We use a X-IS-HUMAN-READABLE
> information in out LdapSyntax elements in ApacheDS, other servers don't.
>
>
>> Or, do you want to also use this list in addition to an already loaded
>> schema?
>>
>
> Yes, if needed (ie, if we can't build it from the schemas we load)
>
>
Cant we just keep this information in a constants file and make sure the
constants are accessible to the API code? Users should be allowed to
override and add more settings at runtime so more attributes can be tweaked?
--
Best Regards,
-- Alex
Re: Binary attributes handling in the API
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
After some talk with Emmanuel, we think we would still need to have a list of binary attributes, in addition to the list of syntaxes which also makes sense.
There are three use-cases:
1°/ The schema is not loaded => We filter binary values using the binary attributes list.
2°/ The schema is loaded, *and* the server indicates if the syntax of the AttributeType is human readable or not => We filter binary values based on this information (that's the most accurate information we could get).
3°/ The schema is loaded, *But* the server DOES NOT indicate if the syntax of the AttributeType is human readable or not => We filter binary values using the binary syntaxes list (first) and binary attributes list (second, if there's no match).
Regards,
Pierre-Arnaud
On 6 févr. 2012, at 16:58, Emmanuel Lécharny wrote:
> On 2/6/12 4:11 PM, Pierre-Arnaud Marcelot wrote:
>> I believe we need this list only in the case where no schema is loaded on the connection, right?
>
> Sadly, no. For servers that don't expose the information about the non human readable Syntax, we have to provide it. We use a X-IS-HUMAN-READABLE information in out LdapSyntax elements in ApacheDS, other servers don't.
>>
>> Or, do you want to also use this list in addition to an already loaded schema?
>
> Yes, if needed (ie, if we can't build it from the schemas we load)
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: Binary attributes handling in the API
Posted by Emmanuel Lécharny <el...@apache.org>.
On 2/6/12 4:11 PM, Pierre-Arnaud Marcelot wrote:
> I believe we need this list only in the case where no schema is loaded on the connection, right?
Sadly, no. For servers that don't expose the information about the non
human readable Syntax, we have to provide it. We use a
X-IS-HUMAN-READABLE information in out LdapSyntax elements in ApacheDS,
other servers don't.
>
> Or, do you want to also use this list in addition to an already loaded schema?
Yes, if needed (ie, if we can't build it from the schemas we load)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Binary attributes handling in the API
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
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
>