[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] DistProc: Kill Name Mapping
At 05:35 PM 8/26/2004, Jim Sermersheim wrote:
>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.
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
>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
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext