Subject: Re: Continuation reference to root DN

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 20 Nov 2002 20:55:42 -0700

What would cause a continuation reference to point to the basedn ""?

Jim

>>> Hallvard B Furuseth <[email-masked]> 11/15/02 08:38AM >>>
The protocol draft says:

> 4.5.3 "Continuation References in the Search Result" says:
>   The SearchResultReference is of the same data type as the Referral. 
>   URLs for servers implementing the LDAP protocol are written according 
>   to [LDAPDN]. The <dn> part MUST be present in the URL,
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What if one wants to specify a search from basedn ""?

-- 
Hallvard

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 21 Nov 2002 06:30:13 -0700

I'm not sure what the problem with this tree is. Are you saying that there is a subordinate reference on the central server that points to the empty DN on the local server?

>>> Hallvard B Furuseth <[email-masked]> 11/21 5:07 AM >>>
Hallvard B Furuseth writes:
>Jim Sermersheim writes:
> I think it would have to be something like this DIT:  (...)

I just thought of a better reason:

planet=Earth  (on central server)
  c=NO        (on local server)
  c=GB
  ...
We'll need this when LDAP gets extended to work over interplanetary
distances.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 21 Nov 2002 14:39:11 +0100

Jim Sermersheim writes:
> I'm not sure what the problem with this tree is. Are you saying that
> there is a subordinate reference on the central server that points to
> the empty DN on the local server?

Yup.

Anyway, as you can hopefully tell, my vote is to disallow subordinate
refs to root.

-- 
Hallvard

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 21 Nov 2002 07:03:42 -0700

Gotcha. This is quickly becoming a non-issue. Might end up just making some clarifications here and there.

Jim

>>> "Jim Sermersheim" <[email-masked]> 11/21 8:30 AM >>>

-- 
Hallvard

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 22 Nov 2002 06:18:28 -0700

I agree. An empty DN makes sense when pointing to a superior reference. And in this case I believe it's always appropriate for the client to replace the empty DN with it's original base DN. If that is so, we can leave things as they are.

Jim

>>> <[email-masked]> 11/21/02 04:36PM >>>
Date sent:      	Wed, 20 Nov 2002 20:50:11 -0700
From:           	"Jim Sermersheim" <[email-masked]>
To:             	<[email-masked]>
Copies to:      	<[email-masked]>, <[email-masked]>, <[email-masked]>,
  	<[email-masked]>
Subject:        	Re: Continuation reference to root DN
Priority:       	non-urgent

> Well, at least one directory implementation has a real entry at the root of the global tree. Thus an alias could point to that entry. I guess that breaks the X.500 data model though and so is the problem of that implementation (it sure is handy to have a place to hang tree-wide policy though).
> 
> So, for the issue I brought up, let me ask if it's OK with the WG that we restrict referrals from pointing to the empty dn.
> 

Jim

I agree that subordinate references should be restricted to not be able to point 
to empty DNs. How can the root of the DIT be subordinate to something else. 
Clearly it cant!.

But an empty DN should be allowed in general, as this will be useful to point to 
superior references, eg as in a server holding an OU to point to the country 
server or org server.

regards

David

> Jim
> 
> >>> Mark Wahl <[email-masked]> 11/20/02 05:48PM >>>
> 
> 
> Jim Sermersheim wrote:
> > 
> > Good point. 4.1.10 is broken when an alias points to the empty DN. One could
> > easily loop on this problem.
> 
> The requirements for continuation references were derived from those of 
> X.500 which tended to point 'across' or 'down'.  It would seem to me that 
> a referral to the root DSE for an operation that is not a baseObject search 
> or Modify on the root DSE would be a 'new feature'.  I don't know an 
> application of this feature that would warrant such a change being required
> to improve interoperability.  Do you know of such application needs?  If 
> so, let's discuss how it uses such referrals to other servers' root DSEs 
> before we discuss making a change to LDAP.  If there aren't, then it might
> be easier to just forbid such references from being created.
> 
> Mark Wahl
> Sun Microsystems Inc.
> 
> 
> 
>