Thank for your answers,
Given the context, I would go for the postaladdress field if the
entries are in RW mode, but if I can't have empty fields, is there a non
ambiguous way to determine the different parts of the field when I use $
as a separator.
The VCard FRC describes an address structure as different components
separated with a semicolon, and the components are :
the post office box;
the extended address (e.g., apartment or suite number);
the street address;
the locality (e.g., city);
the region (e.g., state or province);
the postal code;
the country name (full name in the language specified in Section 5.1)
So translating an vcard address into ldap postaladdress is easy, but is
the opposite possible (if not easy) ?
Le 03/05/2013 13:10, Quanah Gibson-Mount a écrit :
--On Friday, May 03, 2013 7:01 PM +0200 Erwann Abalea
<eabalea(a)gmail.com> wrote:
>
>
>
>
> 2013/5/3 Quanah Gibson-Mount <quanah(a)zimbra.com>
>
>
> --On Friday, May 03, 2013 6:24 PM +0200 Erwann Abalea
> <eabalea(a)gmail.com>
> wrote:
>
>
> Can't you use the postalAddress attribute?
> With your examples, it should be something like:
> postalAddress: 123 1st av$Montreal$QC$GGG RT3$CA
>
> postalAddress: 321 42nd st$Montreal$QC$GGG RT1$CA
>
>
> This is almost the correct way to format it... it should be:
>
> postalAddress: 123 1st av $ Montreal $ QC $ GGG RT3 $ CA
>
>
>
>
> If I correctly read RFC2252, the space character around the "$"
> isn't
> required:
>
>
> postal-address = dstring *( "$" dstring )
>
> dstring = 1*utf8
>
>
>
> And the provided examples don't include such spaces.
Please fix your email client to quote replies properly. ;)
Interesting, I've only ever seen it with spaces around the $'s.
> I would also note that there is no guaranteed return order for
> values
> unless you use weighted attributes.
>
>
>
>
> Is the weighted attribute standardized LDAP, or specific to
> OpenLDAP? I
> can't find supportive definition in RFC45* documents.
This is an OpenLDAP specific overlay (valsort).
> Generally the best thing to do if you are going to have multiple
> addresses (say home, work, business, mailing, etc) is to have custom
> attributes specifically for those addresses
>
>
>
>
> Or maybe a subordinate leaf for each address (with address elements
> splitted in several attributes), to be able to use search filters.
Personally, I would avoid subtrees for this. I prefer to see all my
data for a given user stored with the user entry. But that's me. ;)
I've used custom AUX objectClasses for this in the past to attach to
the person entry if they had a specific type of addr.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration