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 <[EMAIL PROTECTED]> 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
confused 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, [EMAIL PROTECTED], 206-501-9803
