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 : "2.5.4.11=exemple \\+ 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 '2.5.4.11', 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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
