On 21/11/04 6:02 pm, Peter Marschall <[EMAIL PROTECTED]> wrote:
> Hi Chris,
>
> On Sunday 21 November 2004 10:06, Chris Ridd wrote:
>>> Modified: trunk/lib/Net/LDAP/Entry.pod
>>> ===================================================================
>>> --- trunk/lib/Net/LDAP/Entry.pod 2004-10-17 13:24:02 UTC (rev 440)
>>> +++ trunk/lib/Net/LDAP/Entry.pod 2004-11-20 21:30:26 UTC (rev 441)
>>> @@ -230,6 +230,9 @@
>>> ';en-us' => [ 'Bob' ]
>>> }
>>>
>>> +If alloptions is not set or is set to false only the attribute values
>>> +for the exactly matching name are returned.
>>
>> I'm sure the "attribute name" is matched case-insensitively - "CN" matches
>> "cn" etc. Is it worth making this more obvious perhaps by using the
>> name/name;en-us example?
>
> my problem was that I did not know whether the simple
> get_value ("name")
> returns all the values of /^name(?:;.*)?/i or only those of /^name$/i.
>
> If I understand the code correctly, it only returns the values of the latter,
> which I like very much, but which is a bit different from what section 3.5 of
> RFC 2596 suggests.
>
> My comment was intended to make this behavior more clear.
> Being not a native speaker it may not come out as intended.
> Can you rephrase it to make it more clear ?
I think maybe the whole Entry.pod needs a bit of rearranging. It should
start off with some text describing the concept of attribute names and
options, and then include some examples (perhaps cn=Graham Barr and
cn;en-us=Bob instead of the not-really-used attribute "name").
The different settings of alloptions (etc) could give sample output using
those example values. (Sorry about the rotten English, but hopefully you get
what I mean :-)
> Do we need an option that changes the behaviour to the one the RFC suggests ?
> (maybe alloptions => 0 i.e. defined but false ;-)))
I don't know if the behaviour specified by that RFC should be considered
correct or not. Have you looked at the latest ldapbis drafts to see if they
clarify the use of attribute "sub-types"?
> The problem leading to all this was that I wanted to have "ASCII-ified"
> versions of attributes using an attribute option "x-ascii" in my directory to
> make it easier to search the whole directory in an environment with clients
> from countries in different character sets. I wanted to know if I needed to
> change my existing Perl applications in that case.
> (It is hard to search for somebody called "M�ller" in a web-based directory
> application if you do not have the "�" (= ü in HTML) on your keyboard or
> not even in your client's character set ;-)
Can you not just store multiple values for cn?
cn=Hans Muller
cn=Hans Mueller
cn=Hans M�ller
> CU
> Peter
>
> --
> Peter Marschall
> eMail: [EMAIL PROTECTED]
Cheers,
Chris
