Re: general aliasing

[Robert Streich <streich@austin.apc.slb.com>]

> That raises a good question, should the deref return a candidate that
> contains a DN that is not within the requested base and fails the
> original base and scope checks.  My original instinct was no, the
> required base and scope should be adhered to or the client may be
> confused, but perhaps I am wrong.  Anyone else have comments on this?

X.518(93) Section 19.3.2.2.3 says yes.

I also managed to come up with a satisfactory resolution for cycles.
The same section says:

  If _aliasedEntryName_ is a prefix of _targetObject_ or _baseObject_,
  then the alias is excluded from the search because this would cause
  a recursive search with duplicate results.

So you can have cycles, but only when a referral is not involved. If a
referral is involved (a "chaining operation"), then cycle ("loop" is
the term they use) detection is required and avoidance is optional
(15.4). I didn't track down all of the details on loop avoidance as
some of the flowcharts seem to conflict with one another and the text
(as in 20.4.5) and I'm not interested in that problem, at least not
for the moment. This one has already consumed too much time.


> > Since you were working with suffixes, maybe you can answer a question for
> > me. I don't see why in subtree_candidates() it doesn't add a scoping filter
> > if "base" is a suffix. Do you know the logic behind this?
> 
> for subtree, if base is a suffix, the scope is the whole tree.

But you can have entirely different subtrees in the database. Why would
they not scope it to one of those? The only thing that makes it a
single tree is the null node. Under that you could have a set of
subtrees that are completely disparate.

bob

Robert Streich			streich@slb.com
Schlumberger			512-331-3318 (voice)
Austin Research			512-331-3760 (fax)