On Tue, Feb 21, 2012 at 1:07 AM, Emmanuel Lécharny <elecha...@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<elecha...@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
