Subject: [ldapext] DistProc: Kill Name Mapping

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 26 Aug 2004 18:35:06 -0600

All,

In
http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-distproc-00.txt,
the notion of "name mapping" is brought out of the woodwork and exposed
as a very obvious feature of distributed LDAP directories (via the
ContinuationReference.remoteName field). Now that this has happened, I'm
receiving pressure to not only make it non-obvious, but to specifically
prohibit the ability.

Here's the history:

RFC2251 referrals (and searchResultReferences) allow for a DN field to
convey a name to be used in progressing the operation. This is primarily
used when aliases are dereferenced, and for the new base DN for a search
sub operation. It also states that the LDAP URL format is used for
referrals pointing to LDAP servers, and the LDAP URL specification
allows for a DN field. RFC3296 allows for the storage of referral data,
and also states that the LDAP URL form is to be used for referrals which
identify LDAP servers. Furthermore RFC3296 states that the DN field
SHOULD be populated when LDAP URLs are stored as referral information.

Neither of these specifications disallow the DN field of a referral
from naming a DSE which is different from the reference object that
holds the referral. 

And the problem:

Allowing this seems somewhat useful at first (one can glue different
namespaces together), but it gets really ugly really fast. For example
(view diagrams below in a fixed-pitch font): When DSA1 chains a search
request to DSA2, should it transform DN values coming from the
chained-to DSA to names that can be later resolved on DSA1? If not, the
resulting names are useless to the DUA receiving them from DSA1. Also,
look at the case where the OU=Z,OU=Y,O=X group is returned, not only
would the entry name need to be transformed (to OU=Z,DC=B,DC=A), but the
member value would need to be transformed. But transformed to what? DSA1
holds no reference to any parent of the member value.

   DSA1
      O DC=A
     /  (glue)
    /
   O DC=B
     (referral)
       ref=ldap://dsa2/OU=Y,O=X

   DSA2
      O O=X
     / \
    /   \
   O     O OU=Q
  / OU=Y  \
 /         \
O OU=Z      O OU=R
  (group)
    member=OU=R,OU=Q,OU=X

As one attempts to solve these problems (with name mapping tables,
auto-insertion of cross references, etc), even more problems arise until
it feels like trying to unwind a problem that is fractal in nature.
Usually when this happens, one can't help feeling like it was a bad idea
to begin with. Thus, there is a request to:

a) Remove ContinuationReference.remoteName.
b) State that the DN values stored in a referral URI must also name the
reference object on which they are held. Otherwise the DN value is
ignored for purposes of distributing the operation.

What do you all think of these two proposals?

Jim

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 28 Aug 2004 17:55:47 -0700

>receiving pressure to not only make it non-obvious, but to specifically

I would concur that the I-D should not discuss "name mapping"
as you describe it below.  Rewriting of the entry, if a desirable
capability, is beyond the scope of distributed directories.
This I-D (and associated I-Ds detailing model elements) should
avoid discussion of "virtual directory" issues such as how
to do "name mapping".

I have no problem discussing how to handle various forms of
knowledge information described in X.500(93), including
cross references.  I note that in X.500 handling of such
references demands (nor likely allows) "name mapping".

Kurt