Search over referrals (Re: LAST CALL: draft-ietf-ldapext-referral-00.txt)

[Harald Tveit Alvestrand <Harald.Alvestrand@maxware.no>]

Tim, gang:
when reading the referral draft, I started wondering.

The drawing goes like this:


       |------------------------------------------------------------|
       |                    Server A                                |
       | dn: o=abc,c=us                dn: o=xyz,c=us               |
       | ref: ldap://hostB/o=abc,c=us  ref: ldap://hostD/o=xyz,c=us |
       | ref: ldap://hostC/o=abc,c=us  objectclass: referral        |
       | objectclass: referral                                      |
       |____________________________________________________________|

  |---------------------| |---------------------| |---------------------|
  |       Server B      | |       Server D      | |      Server C       |
  | dn: o=abc,c=us      | | dn: o=xyz,c=us      | | dn: o=abc,c=us      |
  | o: abc              | | o: xyz              | | o: abc              |
  | other attributes... | | other attributes... | | other attributes... |
  |_____________________| |_____________________| |_____________________|

A subtree search under o=abc,c=us is well defined.

But: What is going to be returned on a single level search under c=us
for "phone=+47 22 33 44 56"?

There are 3 alternatives:

- Server A holds complete copies of all attributes for the entries
  that have "referral" as its object class. It can answer the
  search without referring.

- Server A holds only the referral data, and returns as many referrals
  as there are second-level servers.

- I have misunderstood something, and there is a third alternative.

I believe a DIT structured as the second alternative will be a total
disaster if one is building a directory with any significant distribution
at all; I can imagine a client chasing 5 referrals; I can *NOT* imagine
a client chasing 20.000 referrals.
(There is no procedure in the draft for merging referrals; even if you
get 20.000 referrals to only 5 servers, there are 20.000 referrals to
be chased).

If we want the first alternative, I believe "Referral" should be an auxillary
object class, not a structural one, and the requirement to shadow the
referred-to entry should be plain in the text.
(Yes, I know X.500 doesn't have this restriction. And I know that the
problem has been encountered in X.500 setups.)

                            Harald A


"Scaling is The Problem. All else is details." (Mike O'Dell)
  

-- 
Harald Tveit Alvestrand, Maxware, Norway
Harald.Alvestrand@maxware.no