--On Wednesday, May 30, 2018 11:40 AM +0200 Michael Ströder
Some more comments on a sub-set of the attributes.
On the attributes related to filesystem paths (logfile, etc), I was going
with case ignore match since olcConfigFile and olcArgsFile are already
caseIgnoreMatch. I.e., the precedent for file paths is already set to be
non-case specific. So it seems to me that olcLogFile, olcPidFile, and
oldModulePath, etc should all be caseIgnoreMatch for consistency.
Any EQUALITY matching rule needed at all?
If yes, use EQUALITY octetStringMatch as with userPassword.
Lack of matching rules is causing problems with cn=config replication,
which isn't really highlighted in ITS#8286 (That problem arose later). So
the goal is to ensure all attributes used by cn=config have matching rules
> olcTCPBuffer -- case ignore match?
Also might contain listener URL. So maybe same like olcReferral even
though an LDAPI URI does not make sense with TCP buffers?
> olcTLSCipherSuite -- case ignore match?
I don't have a strong opinion on that because I don't have an oversight
how the supported crypto libs treat this strings.
Yeah, I'm not entirely sure on this one either.
> olcTLSSECName -- case ignore match?
??? Cannot find this in 2.4 schema. Is that new in 2.5?
Yes, new in 2.5.
> --- dds.c
> olcDDSmaxTtl -- case ignore match?
> olcDDSminTtl -- case ignore match?
> olcDDSdefaultTtl -- case ignore match?
> olcDDSinterval -- case ignore match?
> olcDDStolerance -- case ignore match?
Why are the TTL attributes strings at all? I see no reason why there are
not defined as Integer syntax.
That's a very valid question, since the man page only allows numeric
values. But the schema defines them as directory strings instead of
integers. Looking at RFC 2589, the "entryTTL" that gets added to a dynamic
object is specified as being an integer, so it seems to me that these
attributes which control that value should also be required to be an
integer. Howard, your thoughts? Is this a bug in the design of slapo-dds?
If they are kept as strings, perhaps "numericStringMatch"?
> --- memberof.c
> olcMemberOfDangling -- case ignore match?
This serves as a good example for an enum type. I'd argue that it should
be limited to this particular set of lower-cased values.
Per the code, it already is limited to "ignore" or "drop" or
question here is what matching rule is necessary. As far as I can tell
it'd consider "igNore", "DroP", etc, all valid since it's just
> olcMemberOfGroupOC -- case ignore match?
> olcMemberOfMemberAD -- case ignore match?
> olcMemberOfMemberOfAD -- case ignore match?
AFAICS these always reference a single object class or attribute type.
So why not declare them with syntax OID?
Same suggestion for similar attributes of other overlays.
I'm concerned about changing SYNTAX for already released code.
> olcMemberOfDanglingError -- case ignore match?
Is this just the LDAP error code?
If yes, define it as Integer.
It does seem it would make more sense as an integer. However, I'm not sure
that'd work well as a change for 2.4, perhaps 2.5 only.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: