Re: Named Referrals Questions.

[David Chadwick <d.w.chadwick@salford.ac.uk>]

> 
> When I asked Mark Smith this:
> 
>   A reference that is subordinate to a normal (non-reference) object and
>   that, in turn, has subordinate (directly or indirectly) normal objects
>   held by the same server is difficult to interpret, at least for me. It
>   can be used - I think - to 'glue' together servers which hold objects
>   from the same naming context: some children of an object in one
> server,
>   some in another. I also think that this probably was not the intent.

No this is not correct. THere is no reason to glue together objects 
from the same naming context using references, as all objects in a 
naming context must be held in the same master server (by 
definition). A server that takes a sparse replica of this naming 
context glues them together using glue DSEs, not using references. 
However, the LDUP group have just ruled out sparse replicas as 
being too complex to handle, so they probably wont occur in LDAP 
only servers. The example I gave was of different naming contexts 
(not the same naming context) being held in the same server. This is 
perfectly legitimate. A server can hold multiple naming contexts and 
this should not be ruled out. 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 (these are in 
fact glue DSEs holding a ref attribute)

> 
> He answered this:
> 
>   I agree.  Perhaps that configuration should be disallowed.
> 
> 
> My current position is: name resolution algorithm described/implied in the
> "namedref" ID (and the one from the old/new "knowledge" ID) will not be
> able to attribute any meaning (that I understand) to configurations where
> a reference object is subordinate *and* superior (directly or 

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)



>indirectly)f
> to the non-reference objects held by the same server. It probably can be
> made to work, but 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. 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).


>More importantly, usefulness of
> such configurations is unclear.

Agreed. Some of the more complex configurations are hard to 
envisage a use for, but then designers never can envisage all the 
uses that users will make of their products. This is part of innovation.

> 
> Assuming that such ("reference sandwiched between normal object")
> configurations are disallowed, it is true that:
> 
>   If the only types of references supported are subordinate, superior and
>   immediate superior, 

You also absolutely have to have cross references. YOu certainly 
cannot rule these out as they are essential to good performance in a 
distributed directory.

Finally, at the LSD2 BoF it was suggested that NSSRs also have 
their usefulness, so these should also be included.


>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;

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) Tell me how you will differentiate between myref and 
supr that are both held in the root DSE?

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

It is true if you only store a limited number of knowledge reference 
types as you suppose above, but 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.

Regards

David


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


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email D.W.Chadwick@salford.ac.uk *NEW*
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************