Re: Searching on attributes with spaces (fwd)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:30 AM 9/28/99 -0700, Booker Bense wrote:
>
>- Saw this on the Perl-ldap list, it claims that 
>openldap allows attribute names with spaces in them
>in violation of RFC2251.  


Though I agree it's a bug, I just have to point out a
couple of issues:   OpenLDAP 1.2 implements RFC1777.
RFC1777 doesn't preclude an AttributeType from
containing spaces nor starting with '_'.

   AttributeType ::= LDAPString

Though it says "An AttributeType value takes on as its value
the textual string associated with that AttributeType in the
X.500 Directory standards" but it doesn't actually restrict
which strings you can associate with an X.500 AttributeType.

You could summarize LDAPv2 specs (and this implementation)
as being lazy... one has to be careful as what you specify
and don't specify.

One could argue that we should continue to accept attribute
times of any LDAPString.  This would be in keeping with the
"be liberal in what you accept, be strict in what you speak"
principal.

I guess my take on this is (for 2.0):  if schemacheck is off,
let the user shoot themselves in the foot.  But, if schemascheck
is on, attribute types should be checked for adherence to RFC2251
requirements. 

	Kurt

>
>---------- Forwarded message ----------
>Date: Thu, 23 Sep 1999 21:18:23 -0500
>From: Mark Wilcox <mewilcox@unt.edu>
>To: Graham Barr <gbarr@pobox.com>
>Cc: perl-ldap@mail.med.cornell.edu
>Subject: Re: Searching on attributes with spaces
>Resent-Date: Thu, 23 Sep 1999 22:22:09 -0400 (EDT)
>Resent-From: perl-ldap@mail.med.cornell.edu
>
>I say leave it alone. If someone is stupid enough to violate the specs, they
>should have to fix it, it's not the API's fault they violated the spec.
>
>The PerLDAP team ran into the same problem. They had hash keys that started with
>a _ because you can't have an attribute that starts with a "_" but someone did.
>That person learned the error of their ways :)
>
>
>Mark
>
>Graham Barr wrote:
>
>> According to RFC2251 section 4.1.4/4.1.5
>>
>>    A specification may also assign one or more textual names for an
>>    attribute type.  These names MUST begin with a letter, and only
>>    contain ASCII letters, digit characters and hyphens.  They are case
>>    insensitive.  (These ASCII characters are identical to ISO 10646
>>    characters whose UTF-8 encoding is a single byte between 0x00 and
>>    0x7F.)
>>
>> This states that a space is not a legal charater in an attribute name,
>> which is why Net::LDAP::Filter does not allow them. To change this
>> (although I am not sure we should) Look in Filter,pm for the
>> line
>>
>> my($Attr)  = qw{  [-;.:\d\w]*[-;\d\w] };
>>
>> and change it too
>>
>> my($Attr)  = qw{  [-;.:\d\s\w]*[-;\d\w] };
>>
>> On Thu, Sep 23, 1999 at 06:10:49PM -0700, Scott Kelley wrote:
>> > I've got a few attributes that have spaces in them (ex. "home phone"). When
>> > I try and search on these attributes nothing is returned. I've tried to
>> > escape the spaces in the attributes, quoting the entire filter, but nothing
>> > seems to remedy the situation. If I pass the same filter to OpenLDAP's
>> > ldapsearch utility it works fine. Any thoughts?
>> >
>> > Here's an example filter:
>> >
>> > (home phone=*633*)
>> >
>> > Thanks for your help.
>>
>> --
>> For myself I am an optimist--it does not seem to be much use being
>> anything else. -- Winston Churchill
>
>
>