[Date Prev][Date Next]
Re: Liberal parsing of schema elements (ITS#1996)
I misunderstood the nature of the problem. The
client library ALLOW flags, if properly enabled,
should be able to parse these non-conformant
values. If they aren't working, that's a bug.
Of course, clients must (as in MUST, per RFC 2251)
not send non-conformant values to servers. But
most clients don't re-send values they read from
servers. If they do, they are responsible for
implementing the "strict in what is sent" part of
At 02:53 PM 2002-07-30, email@example.com wrote:
>Kurt D. Zeilenga wrote:
>> To prevent garbage out, we prevent garbage in.
>I understand that OpenLDAP is a reference implementation of LDAPv3
>and therefore the main goal is to strictly adhere to the standards.
>But many people using it as a base for developing client apps
>accessing other LDAP servers violating the standard
>(Netscape/iPlanet DS, Novell eDirectory, Domino/LDAP R5, etc.).
>Regarding this specific issue here you already have some constants
>to allow a more liberal schema element parsing. That's what I
>suggest to leverage. Off course using these flags makes the
>application responsible for sanitizing the data / handle tricky
>situations if necessary.
>Note that I do *not* vote here to make the schema parsing on the
>server-side more liberal. I'm solely talking about client-side
>parsing in my own apps.
>> If someone takes the time to allow garbage in (liberal in
>> what you accept) in a manner which doesn't cause garbage
>> out (strict in what you send), I'm fine with allowing
>> such into the distribution. Patches welcomed.
>Well, this really depends on what you expect the application to
>send. As I said before IMHO schema-aware applications should not
>send an OID in any case. OIDs should be treated as opaque index to
>a local schema registry (except some hard-coded LDAP syntaxes).
>That's how I'm currently designing it for python-ldap. The
>attribute type and object class names are what appear in
>LDAPRequests sent to the LDAP server.