Subject: RE: Draft Minutes from LDAPEXT working group

From: "Howard Chu" <[email-masked]>
Date: Tue, 7 Dec 1999 23:55:35 -0800

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
Mark Wahl
> Sent: Monday, November 29, 1999 8:56 AM

Anything new on this topic yet?

> 7. Referrals
The current draft expired a day or so ago. There are several items in
that draft that seem problematic. I haven't seen the alternate proposal, but
I'd like to see it soon, because the behavior specified in the current draft
really isn't usable. Part of the problem is that RFC2255 isn't explicit
enough about the meaning of an LDAPURL.

Specifically, in the namedref draft section 5.1.1.2, cases 2 and 3 - the
draft specifies that any DN portion of a referral must be stripped before
returning the referral to the client. Nowhere in this doc or in RFC2255 is
an explanation given for what this URL actually means. Judging from what
I've seen in UMich slapd 3.3 for LDAPV2, it appears that an LDAPURL of the
form "ldap://host:port" in a referral means retry the current request using
the original DN, whereas using the form "ldap://host:port/" means use a NULL
DN in the retry. And of course, this is all pretty dodgy because the docs
for referrals in UMich slapd reference an internet draft which I can only
assume was promoted to RFC1959, and in RFC1959 the trailing '/' on the
LDAPURL is *not* optional.

In RFC2255 the trailing '/' *is* optional, but the difference between these
two cases still isn't spelled out. It makes sense that there should be a
difference in meaning between these two cases, because it's reasonable to
want an LDAPURL that can point to the rootDSE of a server.
Whether this is actually the desired behavior or not needs to be explicitly
stated though.

As if that wasn't muddy enough... Back to section 5.1.1.2 in the namedref
draft... What is the purpose in stripping the DN from the referral before
giving it back to the client? Regardless of how the ambiguity of this
stripped referral is resolved, the resulting referral invariably points to
the wrong thing. If I have

   Server A                            Server B
dn: o=abc,c=us                         dn: o=xyz,c=us
o: abc                                 o: xyz
...

dn: ou=foo,o=abc,c=us                  dn: ou=foo,o=xyz,c=us
ref: ldap://hostB/ou=foo,o=xyz,c=us    ou: foo
...                                    ...

then any non-search request through server A to ou=foo,o=abc,c=us
is guaranteed to return an unusable referral to server B.
The DN part of the referral record is essential to the successful resolution
of the referral; it makes no sense to be unconditionally stripping it.

> A work item is the definition of how to manage references between LDAP
> servers.  An earlier draft had specified both the 'simple' behavior, where
> there is both hierarchical name subordination and knowledge of all the
> subordinates, names, as well as a more complex behavior to handle
> potentially
> overlapping or unknown naming contexts.  The former was broken out into
> draft-ietf-ldapext-namedref-00.txt, the latter does not exist in an IETF
> draft at present.  There is a competing proposal for the former
> which also
> covers several inter-X.500-server knowledge cases.  David
> Chadwick was not
> present and so the technical issues were not discussed.  The authors are
> requested to ensure that by the next meeting we have a single
> base document
> on the simple referral behavior that is suitable for last call to
> become a
> Proposed Standard.
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Dec 1999 07:48:35 -0800

At 11:55 PM 12/7/99 -0800, Howard Chu wrote:
>two cases still isn't spelled out.

There is no difference.  Both:
	ldap://server
	ldap://server/

specify invalid searches (a subtree search of a NULL DN is invalid)
but are not invalid URLs.

>It makes sense that there should be a

	ldap://server/??base refers to the rootDSE
	ldap://server/??one refers to top-level entries that might
		by held by the server such as "c=US", "dc=COM"
	ldap://server/??subtree is invalid search

from this:
	ldap://server
	ldap://server/

and represent invalid searches.  However, namedref says
such URLs, when returned as protocol referrals imply that
the client should use the base/DN of the operation which
returned the referral.

Since a server would not ever return a referral "ldap:///??base"
for any operation, no ambiguity exists.

---

From: sanjay jain <[email-masked]>
Date: Wed, 08 Dec 1999 14:11:32 -0800

> specify invalid searches (a subtree search of a NULL DN is invalid)

why subtree search of a NULL DN is invalid ?
Is it mentioned in RFC 2251 ?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Dec 1999 14:23:45 -0800

>but are not invalid URLs.

The assertion that the above URLs represent an invalid search
is likely false and my conclusions may be incorrect.  (Both URLs
do, IMO, represent the exact same search).

A subtree search of a NULL DN is valid, it just shouldn't return
the contents of the Root DSE.
	RFC2251:  The root DSE MUST NOT be included if the client
       performs a subtree search starting from the root.

----
Kurt D. Zeilenga		<[email-masked]>
Net Boolean Incorporated	<http://www.boolean.net/>