directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Dn, Rdn and Ava inconstancies
Date Mon, 20 Feb 2012 23:07:38 GMT
Le 2/20/12 11:58 PM, Alex Karasulu a écrit :
> On Tue, Feb 21, 2012 at 12:49 AM, Emmanuel Lécharny<>wrote:
>> Le 2/20/12 11:20 PM, Alex Karasulu a écrit :
>>>   So, the main issue is the way AVA handles values. As soon as we *know*
>>>> what we should expect when we create an AVA, then suddenly it becomes way
>>>> easier. Basically, an AVA contains one type and one value. This value can
>>>> be a String or a byte[], depending on the type. Saddly, if the AVA is not
>>>> schema aware, we can't tell if the value is binary or String.
>>>>   Sounds like it needs not to be schema aware but binary attribute aware:
>>> a
>>> subset of the schema. This is the first level of correctness.
>> That's not enough. We need to normalize the valus inside the server, and
>> that means we have full access to the schema.
> I meant NOT in the server but in the client. This is the minimum
> requirement for the client.
>>> The next level depends on whether or not we have the full schema available
>>> to properly normalize the value.
>> yep, exactly. Just having the AVA being aware of the type of the value is
>> not enough.
> This is the minimum we need on the server side.
>   SNIP ...
> Basically, we will have two forms for an AVA :
>>>> - a User Provided form (the standard form)
>>>> - a Normalized form which will differ depending on the fact that the AVA
>>>> is schema aware, or not.
>>>>   Note that whether schema aware or UN-aware AVAs will still need to be
>>> binary type aware.
>> Well, not necessarily. When you inject binary values into an AVA, it's
>> generally done through the parsing of a DN or an RDN. In this case, the
>> value will be encoded using an hexstring (#ABCD...).
>> Now, if we don't have a full schema available, we can still manage to
>> determinate if the AVA contains a binary or a String value, as soon as its
>> AT is declared as binary or HR in the default schema.
>> FYI, the current default SchemaManager contains a Map of non HR attributes
>> (we have added all the known binary attributes from the RFC, and it's
>> extensible). This was mandatory in Studio to fix some bad issues we had
>> with certificates last weeks.
> If not already the case, we should make it so users can add to this their
> own user defined binary attributes programmatically for the sake of the
> client API.
> SNIP ...
> Is it worth removing the white space variance which we can do with or
>>> without a schema? You don't need schema to do this right? I'm thinking it
>>> may under certain situations prevent some problems due to case variance on
>>> clients not loading a schema.
>> This is an extremely complex problem. Inside the server, String values
>> must go through a PrepareString process which includes the handling of
>> unisgnificant spaces (see RFC 4518, Appendix B and par. 2.6.1), and the
>> normalization of CN will remove all the leading, duplicate and trailing
>> spaces. How we can keep some spaces the user wants to keep is a problem.
> OK no worries. BTW I was not thinking of this on the server side. I was
> thinking of using this on the client side in the absence of schema. It
> would be a watered down version of the prep string function.

On the client side, we use whatever SchemaManager the user wants to use :
- none
- a default schema : it will have a list of all the binary AT, this list 
is configurable
- a schema loaded from a LDIF file
- a schema loaded from a remote server.

We have all our bases covered.

Emmanuel Lécharny

View raw message