Combined object/referral entries

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Here is a suggestion for Work For Somebody - not for me for a while,
I'm afraid:


It would be useful to have directory objects that can be read and
one-level searched for normally, but which turn into continuation
references if one attempts to go below them.  (Subtree search
through them, or one-level search based at them, and noSuchObject
with matchedDN = such an entry.  Not sure about Bind.)

For that matter, if most of one's clients - or users - do not follow
referrals or references, one might want to return both the object
and the reference, even though that could confuse clients that do
follow references.  Or one could teach clients about such
object/referral entries and add a control similar to Manage DSA IT
which causes object/referral entries to be returned - with the ref
attribute.

One would probably also regularly contact all servers which such
object/referral entries point to, and refresh the entries from these
servers.  That can be left to a client, though - at least for now.

Such entries cannot have the 'referral' object class, since they
already have another structural object class.  So they must instead
use an auxiliary class which allows the 'ref' attribute, or some
other hack.  The options I can think of are:

(1) Use the 'ref' attribute, but without the 'referral' object
    class.  Use an auxiliary 'childReferral' object class instead.
    Unfortunately, where slapd currently turns a search with
    (FILTER) into (|(FILTER)(objectClass=referral)), it must now use
    (|(FILTER)(objectClass=referral)(objectClass=childReferral)),
    or (|(FILTER)(ref=*)) where the administrator should add a
    presence filter for 'ref'.  I imagine the latter is fastest.

(2) Add 'objectClass;not-structural: referral'.  (It's possible to
    add that along with another structural object class now, but
    that doesn't allow the 'ref' attribute to be added - not even
    with extensibleObject.)

(3) Define 'childReferral' to be a subclass of 'referral' and all
    structural object classes in the entry in which it occurs.  Add
    objectclasses 'referral' and 'childReferral'.  Or generalize and
    define a 'bottom' structural object class which is a subclass of
    all structural object classes in the entry in which it occurs.

(4) This is really ugly, but just to have mentioned it:
    Make 'childReferral' an auxiliary subclass of 'referral', and
    let that mean that 'referral' is not considered part of the
    structural object class chain even though it is structural.

An entirely different approach: Could this be made an overlay,
maybe one with its own database of referrals?
If it had a referral at the base DN of a non-base search, it
would just return that referral.  Otherwise, in a subtree search,
it would insert continuation references among the search results
and delete entry responses matching those references.  The search
would have to cooperate somewhat: If it dereferenced an alias
and ended up outside the scope of the original search, it would
have to return that DN to the overlay so that the overlay could
return references in the subtree from that DN too.
Also, the overlay would catch noSuchObjects with matchedDNs that are
referrals in its database.



Next step: Turn back-dnssrv into an overlay which intercepts
noSuchObject responses and saves the SRV entries that it finds to an
LDIF file.  Save these as entry/referral objects, and they will be
refreshed from their respective servers...  Such entries must be
regularly checked against their SRV records, though.

-- 
Hallvard