Re: Named Referrals Questions.

[Leonid Dubinsky <dub@shym.com>]

David Chadwick wrote:

> A server can hold multiple naming contexts and this should not be
> ruled out.

Agreed. This is exactly why immediate superior references are necessary.

> So if we have multiple naming contexts in a server, that are
> hierarchically related, with a "middle" naming context held in a
> different server, then these multiple naming contexts will be held
> together with reference objects.

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.

> this is precisely why I have included the reference type in the ref
> attribute. This tells the server what sort of reference this is. It does
> not need to compute it everytime (which you have just pointed out is
> sometimes difficult if not impossible to compute). The storage
> implication is minimal and the saved processing time could be
> significant (it also makes the coding much easier)
> ...
> I fail to see why you are insisting on using processing power
> everytime to try to recompute a single bit or two that indicates the
> type of knowledge reference (which is impossible anyway in every
> circumstance)

If enough of the reference types are supported, it becomes impossible to
infer the type of the reference, and then it must be stored. I am
insisting that if it *is* possible to infer the type of reference, it's
type should not be stored (unless this inference is ugly or extremely
expensive) - because I do not like redundancy. With subordinate,
superior and immediate superior references and the added restriction on
"sandwiched" references it is possible to infer reference type from it's
position, and the name resolution algorithm is aware of the reference's
position anyway, so saved processing time is zero. The restriction is
unnatural, though. Besides, it seems we need to support more reference
types. So, storing reference type - or some information from which
reference types can be inferred - becomes necessary.


In short: I understand and agree that name resolution algorithm needs to
know the reference type. I just do not see name resolution algorithm
capable of handling all the reference types described in the IDs -
directly *or* by reference.

> > a lot more needs to be said about name resolution
> > algorithm, server confgurations and such.
> 
> X.518 says a lot about distributed name resolution. Perhaps you
> should try reading it.

Thanks for the reference - again.

> Why duplicate and replicate what has already
> been done and proved to work in a distributed environment with
> thousands of interconnected servers (cf the Paradise project).

Why, indeed? If LDAP is to support all the reference types from X.500,
probably LDAP will have to implement full X.518 name resolution
algorithm (minimally adopted to the way references are represented).
LDAP documents should than say so, and either present the algorithm in
full (as applied to LDAP), or include it by reference (saving
duplication/replication, but leaving any LDAP adaptation as an exercise
for the reader).


Regards,

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