LDAP - Question on base64 encoding rules

Author

Question on base64 encoding rules

Ski Kacoroski

2006-10-06, 7:06 pm

Hi,

I am wondering why all attribute values that start with '<' are base64
encoded when then are displayed or written to an ldif file. In
particular, I am using that apple schema and would like to not encode
the apple-user-homeurl attribute which starts with '<' (it is xml code).
Just wondering what the rationale is for this (is it in a RFC?) and if
there is anyway to turn it off for certain attributes.

cheers,

ski

--
"When we try to pick out anything by itself, we find it
connected to the entire universe" John Muir

Chris "Ski" Kacoroski, kacoroski@comcast.net, 206-501-9803

Chris Ridd

2006-10-07, 4:22 am

On 6/10/06 11:47, Ski Kacoroski <kacoroski@comcast.net> wrote:

> Hi,
>
> I am wondering why all attribute values that start with '<' are base64
> encoded when then are displayed or written to an ldif file. In
> particular, I am using that apple schema and would like to not encode
> the apple-user-homeurl attribute which starts with '<' (it is xml code).
> Just wondering what the rationale is for this (is it in a RFC?) and if
> there is anyway to turn it off for certain attributes.

Yes, this behaviour is required by RFC 2849 (the LDIF spec). An attribute
must be written as an attribute type followed by optional things like
language tags or ";binary", followed by a ":", and then either:

optional space and the characters themselves, if they are "safe"

":", optional space, and the base64-encoding if they are not

"<", optional space and a URL

If the value looks like XML then it must start with an "<", and so to avoid
it being interpreted as a URL *must* be encoded using base64. Similarly
values starting with a ":" must be done this way, otherwise they could be

with the second case.

The method that implements this algorithm is Net::LDAP::LDIF::_write_attr
which you could hack up if you really wanted, but you'd have to appreciate
the resulting LDIF file is likely to be mishandled by other tools :-(

The optional space in the three alternates is annoying. If the space was
required, you could have what you wanted :-(

Cheers,

Chris

Ski Kacoroski

2006-10-07, 7:11 pm

Chris,

Thanks for the information. I can see where I would not want to modify
the Net::LDAP library, so I will see if I can modify the tool I use
(ldapsh) to decode and encode these attributes.

ski

Chris Ridd wrote:
> On 6/10/06 11:47, Ski Kacoroski <kacoroski@comcast.net> wrote:
>
>
> Yes, this behaviour is required by RFC 2849 (the LDIF spec). An attribute
> must be written as an attribute type followed by optional things like
> language tags or ";binary", followed by a ":", and then either:
>
> optional space and the characters themselves, if they are "safe"
>
> ":", optional space, and the base64-encoding if they are not
>
> "<", optional space and a URL
>
> If the value looks like XML then it must start with an "<", and so to avoid
> it being interpreted as a URL *must* be encoded using base64. Similarly
> values starting with a ":" must be done this way, otherwise they could be
>

with the second case.
>
> The method that implements this algorithm is Net::LDAP::LDIF::_write_attr
> which you could hack up if you really wanted, but you'd have to appreciate
> the resulting LDIF file is likely to be mishandled by other tools :-(
>
> The optional space in the three alternates is annoying. If the space was
> required, you could have what you wanted :-(
>
> Cheers,
>
> Chris
>
>
>

--
"When we try to pick out anything by itself, we find it
connected to the entire universe" John Muir

Chris "Ski" Kacoroski, kacoroski@comcast.net, 206-501-9803

Sponsored Links