[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Questions about multiple identical values in a field



2013/5/3 Quanah Gibson-Mount <quanah@zimbra.com>:
> --On Friday, May 03, 2013 7:01 PM +0200 Erwann Abalea <eabalea@gmail.com>
> wrote:
>
>> 2013/5/3 Quanah Gibson-Mount <quanah@zimbra.com>
>>> --On Friday, May 03, 2013 6:24 PM +0200 Erwann Abalea <eabalea@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. ;)

That's GMail, multipart/alternative stuff, with inline replying :(
The text/plain part was mostly OK, but it's difficult to manually
read+parse the quoted-printable text/html part...

I have similar problems when using Google Groups.

Switched to pure text, manually added missing quote levels, it should be better.

>>> 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).

Nice to know it's non portable.

>>>   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.

Then a simple copy of "TYPE=HOME:;;123 1st av;Montreal;QC;GGG RT3;CA"
into a custom attribute (with a properly defined auxiliary class)
should get the job done.

--
Erwann.