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

Re: [ldapext] DistProc: Kill Name Mapping

Sounds good.  I'll remove the ContinuationReference.remoteName doohickey
to start with. Then for any DN values appearing in a referralURI, I'll
either ignore the possibility of it being used for name mapping, or I'll
make warning noises about what might happen if it's used for that
purpose (I should note that at least one off-line comment was made which
asked that it not be expressly forbidden).

Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 8/28/04 6:55:47 PM >>>
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

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext