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 ?
Do we need an option that changes the behaviour to the one the RFC suggests ?
(maybe alloptions => 0 i.e. defined but false ;-)))
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 ;-)
CU
Peter
--
Peter Marschall
eMail: [EMAIL PROTECTED]
