Thanks for your reply.
"The LDIF Parser correctly parses and writes MIME BASE64 encoded strings: it tries to perform BASE64 encoding if necessary. One such situation is where there are trailing spaces after attribute values: to make sure another LDIF Parser gets the space, it encodes the attribute as BASE64."
-Second: Well I don't know why this is happening which is why I am here, to get help from someone who knows better. I can certainly confirm that when an attribute has a trailing space and gets updated to IBM DS it is actually stored in base64 encoding. If I read it through SDI again I see it as string because it will convert it back. If I read it through say an openldap client I can see the base64 encoded string. If I remove the trailing space before an update operation I can see that it gets stored as string. Does it seem weird to me? Yes. Have I every noticed this happen before? Nope. I only thought to look at the trailing space because of the above link. Is this a "feature" I could probably do without? Probably. I'm sure there is good reason for it to do it though. But something is certainly encoding the strings with trailing spaces and its not me doing it explicitly.
My assemblyling isn't doing anything complicated - Connector A in iterator mode (connects to LDAP server A) retrieves data and maps all attributes to work. Connector B in update mode (connects to LDAP Server B) and maps all work attributes out. If there is additional information you think might be helpful let me know.
This might just have to be one of those where I cannot right a quick one time assemblyline but will have to explicitly define attributes and trim the ones that are strings with trailing spaces. Unless someone has a better solution which will probably help me down the line as well.
Thanks for taking the time to reply YN.
I wonder there is a missing info here, because the story does not add up.
- First, the LDIF parser in the title. What LDIF parser has anything to do with LDAP to LDAP data transfer? (Note: LDIF parser is a function within SDI)
- Second, SDI encode the attribute to base64 just because of a trailing space? Really? I don't believe so, because I read many address data with trailing space and my address data does not automatically changed to base64 data.
So, there might be something else causing your situation.