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