Re: Named Referrals Questions.

[Leonid Dubinsky <dub@shym.com>]

Christopher Lukas wrote:
 
> Another thing that I'm not particularly clear on is your use of the
> terms "subordinate refs", "immediate superior refs", "superior refs" and
> "glue references".

(I think you mean glue DSEs - at least that is the term David used.)

> While the terms make sense in some ways, it seems
> like you are classifying referrals in some way that they don't really
> need to be. I don't understand how an immediate superior reference would
> be treated differently from a superior reference and so on.

Exactly!! It would be much nicer to treat all the references the same
way, without classifying them.

David wants LDAP to support all X.500 reference types, though; some of
them (supplier/consumer? NSSR? me?) may require special handling, and
thus will probably have to be classified and marked. In David's words:
"when you have a complete set of KRs (including NSSRs, my ref, external
refs etc, ) then you absolutely do need to know the type in order to
perform correct distributed name resolution and operation evaluation. As
a taster, try looking at the simple flow charts in the 88 version of
X.518 and this will show you when you need to know the reference type in
order for name resolution to work correctly."

I still feel that "normal" reference handling should be kept simple,
uniform and reference-type independent. (And "special" references do not
have to be represented by the 'ref' attribute.)

I think that the following algorithm (note minimal tweaks as compared to
the algorithm from the "namedref" ID) can handle "normal" references:


  If a client requests an operation for which the base or target object
is not held by the server,

  1. Remove the leftmost attribute/value pair from the DN.
  2. If the remaining DN is empty - stop and proceed with superior
reference from the root DSE.
  3. If the remaining DN represents a locally held object that contains
a ref attribute - stop and process referral.
  4. If the remaining DN represents a locally held object that does not
contain a ref attribute - stop and return "no such object" result.
  5. Continue with step 1.


With such "general-purpose" references wonderful things are possible,
for instance - a server which holds only references, sort of a "map" for
a set of servers.

Example configuration you described will also work, but note:

> If a client performs a subtree search on server A starting at "o=UW
> ,c=US", it will get all matching entries from A within that scope.
> The client will also receive the referral to server B and perform a
> subtree search there with a new base "univ=Madison,o=UW,c=US" and
> get the appropriate entries.

... and, if everything is properly interconnected, among the results
returned by server B will be a referral to server A with base
"dept=cs,univ=Madison,o=UW,c=US". The client will then perform a subtree
search there and get the entries which it already got in response to the
original search.


-- 
Leonid Dubinsky                  Engineer
All opinions are mine, not my employer's.