Re: advertising compiled-but-not-instantiated overlays

[masarati@aero.polimi.it]

> 2.4.18 releases slapo-sssvlv. Now my servers are advertising
> VLV/sortKeyList as supportedControls. Thing is, I don't specify "overlay
> sssvlv" so they're not really "supported" in any meaningful way. Searches
> that specify the controls just error out fast. I'm not particularly
> inclined to enable the feature, but I'm not sure if somebody else might
> want it in their installation, so I'd prefer to keep it compiled in.
>
>
> This is the case with all overlays across the board. For example,
> configure --enable-modules --enable-overlays=mod and syncprov isn't
> advertised in test000. But if you just ./configure and run test000, you
> see 1.3.6.1.4.1.4203.1.9.1.1 despite the fact that there's no way test000
> could provide LDAP Sync as configured. (Recall that --enable-syncprov
> defaults to yes.)
>
> To me it's counterintuitive and "false advertising": unless there's an
> "overlay syncprov" in slapd.1.conf, I don't see why that should show up in
> test000. Thoughts?

This is not in violation of LDAP specs.  Note that advertising a
feature/control/etc. does not imply that the corresponding feature is
always supported for whatever operation.  For example, as you say, VLV
would be supported by the database that instantiates that overlay but not
by others.  Or PagedResults would be supported by back-bdb/hdb but not by
other backends, and so on.  The advertisement via rootDSE mechanism is
inherently flawed, and should be taken as it is: a mention of the fact
that the feature in general could be supported, or at least recognized. 
In fact, OpenLDAP's slapd used to advertise this feature way before it was
actually implemented, and it would simply refuse to use it, after
acknowledging that the feature was recognized.  This is perfectly inline
with LDAP specs.

p.