directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Dn, Rdn and Ava inconstancies
Date Mon, 20 Feb 2012 22:49:46 GMT
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.
> 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.
>> Now, come the Schame into the game. A Schema aware AVA will be able to
>> determinate if the value is binary or not, and will modify the interned
>> value by applying a normalization method (accordingly to the
>> AttributeType). This will impact the String representation of the AVA when
>> used in a RDN (not in the entry), when the user wants to manipulate the RDN
>> as a String.
>> 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.
>> Here is a small table representing the different forms for each of the
>> methods exposing an AVA content :
>> Considering that we want to create the following AVA :
>> "OU" with the value "Exemple + Rdn\u00E4"
>> (note that the value has a space at the end, contains a '+' and a 'ä'
>> character - which is representing using the \u00E4 unicode sequence in a
>> Java string)
>> 1) The Ava.getNormName() method will return :
>>   - No Schema    : "ou=Exemple \\+ Rdn\\C3\\A4\\ "
>>   - With Schema : " \\+ rdn\\C3\\A4"
>> As we can see, the getNormName() return a String so the value must be
>> escaped. As we dont know what kind of normalizer to use when we don't have
>> a schema, in the first case we still have 'ou' instead of '', and
>> the upper case chars remain upper cased. The 'ä' character is translated to
>> its UTF-8 encoding and escaped counterpart, ie C3 A4. Last, not least, the
>> end space is kept when we don't have a schema, but removed due to the
>> normalization when we have a schema.
> 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.

The main issue is that the Ava constructor takes two parameters, the 
type and the value (plus the SchemaManager if needed). If the user wants 
the value to contain a trailing space that will be kept, there is no way 
to do it when the AT normalizer removes the trailing spaces (like for 
the cn). Although, when a user is looking for en entry using its DN, 
then the space will have to be escaped. Sadly, as this trailing space 
will not be stored in the Value, we may have a problem.

Clearly, this is a loophole. However, a very minor one, IMO. Fixing it 
would require that the normalizer is smarter than what it currently is.

Emmanuel Lécharny

View raw message