Re: namedref-00: manageDsaIt question

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

Date sent:      	Thu, 05 Aug 1999 14:37:17 -0700
To:             	d.w.chadwick@salford.ac.uk
From:           	"Kurt D. Zeilenga" <Kurt@OpenLDAP.Org>
Subject:        	Re: namedref-00: manageDsaIt question
Copies to:      	ietf-ldapext@netscape.com

> Here is another example:
> 
> Server A masters "o=abc,c=us"
> Server B masters "ou=hq,o=abc,c=us"

Fine. This is a valid example.

> 
> As such, the are separate naming contexts as they are mastered
> by different servers.
> 
> Server A and B cross replica.  In addition server C replicates
> just "o=abc,c=us" and a server D replicates just "ou=hq,o=abc,c=us"
> (servers C and D demonstrate that the DITs and DSAs are separately
> administrated but otherwise not used in this example).  All naming
> contexts use single-master replication policies.
> 
> In name context "o=abc,c=us", the following named reference exists:
>  dn: ou=hq,o=abc,c=us
>  ou: hq
>  ref: ldap://A/ou=hq,o=abc,c=us
>  ref: ldap://B/ou=hq,o=abc,c=us
>  ref: ldap://D/ou=hq,o=abc,c=us
>  objectclass: referral
>  objectclass: extensibleObject

X.500 does not actually work like this. A server merges its naming 
contexts into one unified DSA Information Tree containing DSEs. 
Therefore a DSA would hold a DSE named ou=hq,o=abc,c=us and 
this would be flagged of type entry, copy, and subr. Its contents 
would be the union of your DSE above and the actual entry contents.

> 
> and the entries "o=abc,c=us" and "ou=hq,o=abc,c=us" both exist in their
> respective naming contexts.
> 
> A. If a client does a ManageDSAIT enabled base search for
> "ou=hq,o=abc,c=us" against server A, A could respond with either
>  1. the actual "ou=hq,o=abc,c=us" entry or
>  2. the referral object "ou=hq,o=abc,c=us" held in "o=abc,c=us" context.

Wrong for X.500. Answer 1 is the only possible answer for an X.500 
DSA. A referral would NEVER be returned in this scenario, since 
the DSA can fully answer the user's query. However, the user can 
choose to ask for the ref attribute to be returned or the user's 
telephone number attribute or whatever else he chooses. And this is 
independent of the ManageDSAIT control.
(I am assuming here that when you mention the referral object in 2 
that you mean a referral response and not the ref attribute. Or am I 
misinterpreting you?)

> 
> B. If a client does a ManageDSAIT enabled base search for
> "ou=hq,o=abc,c=us" against server B, B could respond with either
>  1. the actual "ou=hq,o=abc,c=us" entry or
>  2. the referral object "ou=hq,o=abc,c=us" held in "o=abc,c=us" context.
> 

Again for an X.500 server answer 1 is the only possible answer.

> Per my reading of the namedref draft, case 1 would have to be
> returned in both case A and case B. 

Excellent. Then this is fully conformant with the X.500 model.

> However, this disallows
> modification the referral object held in the "o=abc,c=us" naming
> context. 

Not so. In this case a Search operation is not issued, but rather a 
MOdify entry operation, quoting the ref attribute as the one to be 
updated, and using the ManageDSAIT control. If however, the 
manageDSAIT was NOT set, then the server would return a referral 
to the user, since the server knows that it does not hold the master 
entry, as the DSE is flagged as a copy, and copies cannot be 
updated.
I hope this clarifies things, and shows the difference between 
updates and retreivals. (Things of course will be different in the 
multimaster case when copies can be updated)

David


> 
> Kurt
> 
> 


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

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

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