Chris Ridd schreef:
On 14/1/06 7:08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
LS,
Net::LDAP::Schema has the capabilities of returning a definition of an
attribute including matchingrules etc.
On the standard OL 2.2 schema this works fine for an attribute like email:
$VAR1 = {
'equality' => 'caseIgnoreIA5Match',
'name' => 'email',
'oid' => '1.2.840.113549.1.9.1',
'substr' => 'caseIgnoreIA5SubstringsMatch',
'desc' => 'RFC2459: legacy attribute for email addresses in DNs',
'aliases' => [
'emailAddress',
'pkcs9email'
],
'type' => 'at',
'syntax' => '1.3.6.1.4.1.1466.115.121.1.26',
'max_length' => '128'
};
NB we should probably rename "max_length", because it isn't a maximum length
it is a *minimum* length. See the last para of RFC 2252 4.3.2.
However when I ask for CN , I only get:
$VAR1 = {
'desc' => 'RFC2256: common name(s) for which the entity is
known by',
'sup' => [
'name'
],
'name' => 'cn',
'oid' => '2.5.4.3',
'aliases' => [
'commonName'
],
'type' => 'at'
};
This seems to be the same as the definition in RFC 2256, apart from the
'desc' text.
Now, I can ask for the definition of "name" and fetch the matching rules
from there,
Yes. This is the purpose behind attribute supertypes.
or I can walk through all_matchingruleuses to see which one
contains CN.
That would suck, and not be possible if matchingRuleUses were not readable.
Use the supertype hierarchy.
Cheers,
Chris
Hm, the way I read RFC 2252 4.3.2 it means suggested maximum (<quote>A
suggested minimum *upper* bound</quote>). The client is advised to stay
below this number of bytes/chars but the server should allow for more.
So it seems the server can safely ignore this ;-)
Given the fact that an attribute can have multiple supertypes (its an
array), is there a chance that this will result in conflicting matching
rules ? (e.g. caseIgnore and caseSensitive). Or is it up to the server
to check this when loading the schema ?
Cheers,
Hans
