Re: Named Referrals Questions.

[Leonid Dubinsky <dub@shym.com>]

In response (thank you!) to my questions, David Chadwick wrote:

> > QUESTION 1.
> 
> Agreed. YOu should be able to have a ref to c=us and one to
> c=us,o=bigco immediately beneath each other. Nothing wrong with
> this.

I still think this should be stated explicitly in the draft.

> > QUESTION 2.
> >
> > The draft seems to also imply that objects with a 'ref' attribute can have
> > "normal" subordinate objects held by the same server. This can be used to
> > make superior referrals smart, i.e. to keep superior referrals for each
> > naming context held by the server in an object superior to that naming
> > context.
> >
> 
> Can we use correct terminology here please. Immediately superior
> references (from X.518) are references which point to the naming
> context immediately superior to the one held in this server (your so-
> called smart superior references). They are no smarter than any
> other type of reference, they are just another sort of reference.

Quote from the "Understanding and Deploying LDAP Directory Services" by
Howes, Smith and Good, page 266: "The *default referral* ... The other
type of referral...,  a *smart referral*, is essentially a subordinate
reference".

I think the authors called this "other type of referral" smart because
it has a distinguished name and is more specific then the default
(superior) referral. Dumb (default superior) is the same for all naming
contexts held by a server. The use of referrals I suggested is smart in
the same sense, hence the name I used - "smart superior referrals".

I will gladly use correct terminology - by which you mean, I think,
X.500 (X.518) terminology - now that you confirmed that:

> These are exactly analogous to immediately superior references from X.518.


> I agree with you that these references are useful.

For situations like "directory hosting" - which, if it does not happen
yet, is IMHO imminent - immediate superior references are *essential*.
Nobody - so far - disagreed with their usefulness. It would be nice to
see confirmation from the ID authors that they are aware of the
situation and that this will make it into the ID.

My original questions 1 and 2 arose when I tried to deduce the meaning
of the ID. First deduction turned out to be correct: it's result was
intended, just not spelled out. The second - surprisingly! - turned out
to be useful according to multiple opinions, but not even implied in the
text. I would like the ID to describe possible configurations and
intended use of referrals clear enough that a reader who did not
participate in writing it would not need to perform such deductions,
seeing that they are not only difficult, but also unreliable.


> It will be a trivial matter to add then to my knowledge ID that is about to be published.

It is a trivial matter to add them to the "namedref-00" ID also - with
minimal changes to the algorithm described on page 7 of the ID: instead
of stopping at the "root of the locally held part of the DIT", stop when
the "remaining DN is empty".

If the only types of references supported are subordinate, superior and
immediate superior, the type of the reference can be determined from
it's location: subordinate references do not have non-reference objects
subordinate to them in the same server; immediate superior references do
not have non-reference objects superior to them in the same server;
superior reference is stored in the root DSA. Thus, type of the
reference does not need to be stored, and is not even used by the name
resolution algorithm.


I had another question, which still goes unanswered for some reason:

WHEN DOES THE SERVER RETURN "NO SUCH OBJECT" RESULT IN THE PRESENCE OF
REFERENCES?

I think that the answer should be: "when an object requested is not held
by the server but: 1) is subordinate to a non-reference object held by
the server, and 2) there are no reference objects held by the server
located between this non-reference object and the requested object." 
(This sounds more evolved than it looks on a picture (on as part of a
name resolution algorithm)).

I REALLY THINK THAT SOME ANSWER TO THIS QUESTION NEEDS TO BE IN THE ID.


And the final question:

Is object class 'referral' is structural or auxiliary?

  o  Original "referral-00" ID (March 13, 1998) says structural.

  o  Tim Howes (this list, March 23, 1998) says: "Probably making
referral auxiliary is a better way to do it than what's currently in the
draft (structural + allows any attribute - which is probably not really
legal). ... I'll make this change unless somebody stops me."

  o  "Understanding and Deploying LDAP Directory Services" says
auxiliary.

  o  The "namedref-00" ID says structural.

  o  Mark Smith says: "Our book says auxiliary but I think that is an
error (maybe it was auxiliary in earlier drafts -- I am not sure). We'll
fix that in a future revision of the book."

  o  David Chadwick's updated ID (circulated on this list on July 4)
says auxiliary.


This remains a mystery to me.



All the best and thank you all for your time!


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