[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Named Referrals Questions.



Leonid Dubinsky wrote:
> Key word here is "hierarchically related". I agree that this is
> legitimate and should be allowed. I do not see how name resolution
> algorithms presented in both referral-related IDs can handle this,
> though.

To be honest, I'm a bit confused about what exactly the problems are.
Although I looked at your example, it would be helpful (to me) to
illustrate the problems with more specific examples. Here's what I
gather you are talking about:

We have 2 servers, A and B. A holds the following naming contexts
(apologies for the me-specific examples):

o=UW,c=US 
dept=CS,univ=Madison,o=UW,c=US

B, on the other hand, holds this:

univ=Madison,o=UW,c=US

You are saying that this configuration won't work with the current
referral drafts, correct? 

Suppose server A had the following referral:

dn: univ=Madison,o=UW,c=US
ref: ldap://serverB/univ=Madison,o=UW,c=US

It seems like this would work reasonably well. 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. For other
types of searches and scopes, this seems to work also. 

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". 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.

Could someone please illustrate the problems with specific, detailed
examples? 


Thanks.

- Chris





------------------------
Christopher E. Lukas
Internet Scout Project 
http://scout.cs.wisc.edu