directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Dn, Rdn and Ava inconstancies
Date Mon, 20 Feb 2012 22:58:02 GMT
On Tue, Feb 21, 2012 at 12:49 AM, Emmanuel Lécharny <elecharny@gmail.com>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.

-- 
Best Regards,
-- Alex

Mime
View raw message