RE: Draft Minutes from LDAPEXT working group

[Howard Chu <hyc@highlandsun.com>]

> From: Mark.Wahl@INNOSOFT.COM [mailto:Mark.Wahl@INNOSOFT.COM]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.
>