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 Tue, 21 Feb 2012 01:34:19 GMT
On Tue, Feb 21, 2012 at 1:07 AM, Emmanuel Lécharny <elecharny@gmail.com>wrote:

> Le 2/20/12 11:58 PM, Alex Karasulu a écrit :
>
>  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.
>>
>
> 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.
>
>
Lovely!

-- 
Best Regards,
-- Alex

Mime
View raw message