On Tue, Feb 21, 2012 at 1:07 AM, Emmanuel Lécharny <firstname.lastname@example.org>
Le 2/20/12 11:58 PM, Alex Karasulu a écrit :
On the client side, we use whatever SchemaManager the user wants to use :
On Tue, Feb 21, 2012 at 12:49 AM, Emmanuel Lécharny<email@example.com>wrote:
Le 2/20/12 11:20 PM, Alex Karasulu a écrit :
I meant NOT in the server but in the client. This is the minimum
So, the main issue is the way AVA handles values. As soon as we *know*
That's not enough. We need to normalize the valus inside the server, and
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:
subset of the schema. This is the first level of correctness.
that means we have full access to the schema.
requirement for the client.
This is the minimum we need on the server side.
The next level depends on whether or not we have the full schema available
yep, exactly. Just having the AVA being aware of the type of the value is
to properly normalize the value.
Basically, we will have two forms for an AVA :
If not already the case, we should make it so users can add to this their
Well, not necessarily. When you inject binary values into an AVA, it's
- a User Provided form (the standard form)
binary type aware.
- 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
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.
own user defined binary attributes programmatically for the sake of the
Is it worth removing the white space variance which we can do with or
OK no worries. BTW I was not thinking of this on the server side. I was
without a schema? You don't need schema to do this right? I'm thinking it
This is an extremely complex problem. Inside the server, String values
may under certain situations prevent some problems due to case variance on
clients not loading a schema.
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.
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.
- 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.