Values normalization and special characters

[Emmanuel Lecharny <el...@gmail.com>]

Hi guys,

I'm a bit deeper into the DN/RDN problem. Now, the issue I have is that 
I don't know how we should handle shuch case :
- an AT like "cn: \ user" having an escaped space at the beginning.
- an entry which DN is "cn=\ user,ou=system"

The check is done internally comparing the RDN ("cn=\ user") and the 
Attribute value. Sadly, when we parse the DN, we remove the '\' (as it's 
not significant), keeping the leading space. But then, we normalize the 
RDN applying the CN normalizer to it, which removes the leading space.

At this point, we are in a dead end... Either we keep the '\' in the 
RDN, but that would make the comparison complex, or we consider that 
escaped spaces are just insignificant, but we breach the RFC. However, 
leading spaces and trailing spaces are most certainly not useful, so 
breaking the RFC would be acceptable, IMO.

Do you have any better idea ?

Note : there is no place in the RFC where we are told how to manage 
attribute values with escaped chars... (still have to check though...)

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Values normalization and special characters

[Emmanuel Lécharny <el...@apache.org>]

On 6/7/11 8:56 AM, Stefan Seelmann wrote:
> On Tue, Jun 7, 2011 at 8:49 AM, Emmanuel Lécharny<el...@apache.org>  wrote:
>> On 6/7/11 8:26 AM, Stefan Seelmann wrote:
>>> On Tue, Jun 7, 2011 at 8:09 AM, Emmanuel Lecharny<el...@gmail.com>
>>>   wrote:
>>>> Hi guys,
>>>>
>>>> I'm a bit deeper into the DN/RDN problem. Now, the issue I have is that I
>>>> don't know how we should handle shuch case :
>>>> - an AT like "cn: \ user" having an escaped space at the beginning.
>>>> - an entry which DN is "cn=\ user,ou=system"
>>>>
>>>> The check is done internally comparing the RDN ("cn=\ user") and the
>>>> Attribute value. Sadly, when we parse the DN, we remove the '\' (as it's
>>>> not
>>>> significant), keeping the leading space. But then, we normalize the RDN
>>>> applying the CN normalizer to it, which removes the leading space.
>>> Here we should not compare the RDN and the attribute value. Instead
>>> the RDN's AVA value need to be used for comparison. The RDN AVA value
>>> should not contain the '\'.
>> It does not contain the '\', but the space is also stripped. So "cn: \ User"
>> is internally transformed into an AVA containing "user" as a value (the \
>> and the space are removed after the value normalization...
> Yes, that sounds ok. But the space should also be removed from the
> attribute value during normalization, so the normalized attribute
> value should also be "user".
>
> Is the space removed from both, the normalized value and user provided
> value? It should only be removed from the normalized value.
The Up value remains the same.

What bugs me is that there is no reason to escape a space if it will be 
removed by the normalization...

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Values normalization and special characters

[Stefan Seelmann <se...@apache.org>]

On Tue, Jun 7, 2011 at 8:49 AM, Emmanuel Lécharny <el...@apache.org> wrote:
> On 6/7/11 8:26 AM, Stefan Seelmann wrote:
>>
>> On Tue, Jun 7, 2011 at 8:09 AM, Emmanuel Lecharny<el...@gmail.com>
>>  wrote:
>>>
>>> Hi guys,
>>>
>>> I'm a bit deeper into the DN/RDN problem. Now, the issue I have is that I
>>> don't know how we should handle shuch case :
>>> - an AT like "cn: \ user" having an escaped space at the beginning.
>>> - an entry which DN is "cn=\ user,ou=system"
>>>
>>> The check is done internally comparing the RDN ("cn=\ user") and the
>>> Attribute value. Sadly, when we parse the DN, we remove the '\' (as it's
>>> not
>>> significant), keeping the leading space. But then, we normalize the RDN
>>> applying the CN normalizer to it, which removes the leading space.
>>
>> Here we should not compare the RDN and the attribute value. Instead
>> the RDN's AVA value need to be used for comparison. The RDN AVA value
>> should not contain the '\'.
>
> It does not contain the '\', but the space is also stripped. So "cn: \ User"
> is internally transformed into an AVA containing "user" as a value (the \
> and the space are removed after the value normalization...

Yes, that sounds ok. But the space should also be removed from the
attribute value during normalization, so the normalized attribute
value should also be "user".

Is the space removed from both, the normalized value and user provided
value? It should only be removed from the normalized value.

Kind Regards,
Stefan

Re: Values normalization and special characters

[Emmanuel Lécharny <el...@apache.org>]

On 6/7/11 8:26 AM, Stefan Seelmann wrote:
> On Tue, Jun 7, 2011 at 8:09 AM, Emmanuel Lecharny<el...@gmail.com>  wrote:
>> Hi guys,
>>
>> I'm a bit deeper into the DN/RDN problem. Now, the issue I have is that I
>> don't know how we should handle shuch case :
>> - an AT like "cn: \ user" having an escaped space at the beginning.
>> - an entry which DN is "cn=\ user,ou=system"
>>
>> The check is done internally comparing the RDN ("cn=\ user") and the
>> Attribute value. Sadly, when we parse the DN, we remove the '\' (as it's not
>> significant), keeping the leading space. But then, we normalize the RDN
>> applying the CN normalizer to it, which removes the leading space.
> Here we should not compare the RDN and the attribute value. Instead
> the RDN's AVA value need to be used for comparison. The RDN AVA value
> should not contain the '\'.
It does not contain the '\', but the space is also stripped. So "cn: \ 
User" is internally transformed into an AVA containing "user" as a value 
(the \ and the space are removed after the value normalization...


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Values normalization and special characters

[Stefan Seelmann <se...@apache.org>]

On Tue, Jun 7, 2011 at 8:09 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi guys,
>
> I'm a bit deeper into the DN/RDN problem. Now, the issue I have is that I
> don't know how we should handle shuch case :
> - an AT like "cn: \ user" having an escaped space at the beginning.
> - an entry which DN is "cn=\ user,ou=system"
>
> The check is done internally comparing the RDN ("cn=\ user") and the
> Attribute value. Sadly, when we parse the DN, we remove the '\' (as it's not
> significant), keeping the leading space. But then, we normalize the RDN
> applying the CN normalizer to it, which removes the leading space.

Here we should not compare the RDN and the attribute value. Instead
the RDN's AVA value need to be used for comparison. The RDN AVA value
should not contain the '\'.

> At this point, we are in a dead end... Either we keep the '\' in the RDN,
> but that would make the comparison complex, or we consider that escaped
> spaces are just insignificant, but we breach the RFC. However, leading
> spaces and trailing spaces are most certainly not useful, so breaking the
> RFC would be acceptable, IMO.
>
> Do you have any better idea ?
>
> Note : there is no place in the RFC where we are told how to manage
> attribute values with escaped chars... (still have to check though...)
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>

Re: Values normalization and special characters

[Kiran Ayyagari <ka...@apache.org>]

On Tue, Jun 7, 2011 at 11:39 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi guys,
>
> I'm a bit deeper into the DN/RDN problem. Now, the issue I have is that I
> don't know how we should handle shuch case :
> - an AT like "cn: \ user" having an escaped space at the beginning.
> - an entry which DN is "cn=\ user,ou=system"
>
> The check is done internally comparing the RDN ("cn=\ user") and the
> Attribute value. Sadly, when we parse the DN, we remove the '\' (as it's not
> significant), keeping the leading space. But then, we normalize the RDN
> applying the CN normalizer to it, which removes the leading space.
>
> At this point, we are in a dead end... Either we keep the '\' in the RDN,
> but that would make the comparison complex, or we consider that escaped
> spaces are just insignificant, but we breach the RFC. However, leading
> spaces and trailing spaces are most certainly not useful, so breaking the
> RFC would be acceptable, IMO.
>
> Do you have any better idea ?
>
I don't find(or haven't seen) any real use/need of a space in the DN,
so I do think that removing spaces is 'Ok'.
> Note : there is no place in the RFC where we are told how to manage
> attribute values with escaped chars... (still have to check though...)
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>



-- 
Kiran Ayyagari