[Date Prev][Date Next] [Chronological] [Thread] [Top]

[ldapext] DistProc: Kill Name Mapping

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
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext