2

Just beginning with LDAP and have imported outlook records into a directory. that look like this: enter image description here

Have also edited individual addresses in in the Apache Directory Studio any number of ways to show the street, and city, state on separate lines like a conventional address would look enter image description here

but later looking at them from the address book they appear as:

enter image description here

obviously the $ is used to wrap the second part of the address, but is there a way to not show that in the address book output? a different character in substitution?

What is doing this? Apache Diretory Studio is showing it as a comma, but in edit mode it shows nothing. And does it matter at all? or just a potential confusion for users?

I might add, that adding the contact back to an outlook client pulls in the $

Using ApacheDS which may have some peculiar impact on this or not.

datatoo
  • 3,440
  • 20
  • 31

2 Answers2

2

This link has the information describing the format of the postalAddress attribute.

Terry Gardner
  • 957
  • 8
  • 11
  • Thanks for this. I do see that the '$' is part of how the encoding should be, but don't understand what that means, if I want to just show a CrLf instead. Or if it is even possible. – datatoo Feb 19 '12 at 19:06
  • The `$` is used to separate portions of `t16string` components. Code that desires to display the address should change the record separators to the correct characters according to the local encoding. – Terry Gardner Feb 19 '12 at 21:33
0

Have you looked at the syntax of that attribute? I happen to know in eDirectory that postalAddress uses a funky syntax that has 6 components. You would see them # separated in eDirectory.

I wonder if your directory service (undisclosed) has some interesting syntax for this attribute, beyond simple strings?

geoffc
  • 1,133
  • 2
  • 16
  • 28
  • I just noted the server which is AcpacheDS, perhaps you are right. I do find it weird that outlook concatenates all these fields anyway, rather than allowing individual fields. Seems ripe for errors in parsing – datatoo Feb 10 '12 at 04:15
  • Its a bad choice of a field on Outlooks point. – geoffc Feb 10 '12 at 12:53