[python-ldap] Ldif parser bug?

[Michael Ströder]

Michael Ströder wrote:
> Petr Spacek wrote:
>> On 30.9.2015 10:30, Michael Ströder wrote:
>>> Tobias Diaz Diaz-Chiron wrote:
>>>> Ok, thank you... I'm working on that...
>>>>
>>>> My LDIF is obtained from a telecom server that send users data in ldif
>>>> format. In the ldif some DNs has spaces and some not...
>>>
>>> Thinking about this FILL some more I wonder how leading spaces in attribute
>>> values shall be handled. This might get complex and I'm a bit concerned of
>>> interop issues.
>>>
>>> First try to fix your specific case in LDIFParser._next_key_and_value()
>>> probably a *appending* another specific elif clause.
>>
>> I do not have reference to spec at hand but I believe that all values starting
>> or ending with whitespace should be base64-encoded to avoid ambiguity.
> 
> Unfortunately it's not that clear.
> 
> From RFC 2849:
> 
>       8)  Values or distinguished names that end with SPACE SHOULD be
>           base-64 encoded.
> 
> This is only a SHOULD and AFAICS it says nothing about leading spaces. So
> handling *SPACE as 0 or more space chars would require an lstrip() when
> extracting the attribute value after colon. But this might not meet the
> expectation of some LDIF producers trying to encode leading space(s) like this:
> 
> foo:  bar
> 
> And even this will be ambigous:
> 
> foo: bar

Hopefully other implementors respond to this:

https://mailarchive.ietf.org/arch/msg/ldapext/mqLkF_ELVUZPD-6oiWUcX_x46Qg

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150930/1f07ffe3/attachment.bin>