Re: draft-ietf-ldapext-locate-04.txt

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:12 PM 9/2/00 -0700, Bruce Greenblatt wrote:
>I was thinking that this might be useful in various migration and coexistence scenarios.

Migration to/from what?  coexistance with what?
Traditional X.500 naming? Arbitrary (private) naming?

DNS location issues aside, how would this work?  Would there be a
requirement that the two coexisting schemes produce the same
number of components?

If I understand what you're suggesting (which I admit I might
not), let's say an organization was trying to migrate from
        o=OpenLDAP Project, c=US
to a DN based upon their domain (which happens to have two components)
        dc=OpenLDAP,dc=Org
You are apparently suggest that we, for migration and coexistance
purposes, use the DN:
        o=OpenLDAP Project + dc=OpenLDAP, c=US + dc=Org
I don't see how this helps us migrate to:
        dc=openldap,dc=org

And what if the number of RDNs vs domain components aren't the
same?
        o=openldap.org to dc=openldap,dc=org
        o=OpenLDAP,st=California,c=US to dc=openldap,dc=org

You'd need to allow something like:
        o=openldap.org + dc=openldap.org
nor
        o=OpenLDAP + dc=openldap, st=California, c=US + dc=org

OR you could define some alternative naming scheme:
        o=openldap + d=openldap.org, st=california, c=us

where d is the domain and the first (left to right) is used for
location.  Of course, you could just use associatedDomain (with
or without using it for naming).

>It seems to me that there is no added difficulty as long as there is only one dc attribute value in the RDN.  In doing the mapping to a host name, the algorithm can just ignore the non-dc attribute-value pairs in the RDN.

I really don't think the locate I-D should change the mappings
defined by RFC 2247.  The I-D should provide location services
for DN derived from and based upon RFC 2247 defined one-to-one
domain-DN mapping/naming scheme.  The I-D should provide an algorithm
of how to apply the RFC 2247 mapping and location services for all
DC-based DNs and their children.

I believe defining alternative mappings/naming/location schemes
should be left to other documents.

>I think that the draft is just a little restrictive in this respect
>for no particular gain.

Bijective domain-DN mapping makes sense for a number of reasons,
but primarily because it provide name equivalence between
two different naming systems.

However, with this aside, please note that multi-valued RDNs is
a solution to gain naming uniqueness, not migration/coexistance
between alternative X.500 naming schemes.  Migration from one
naming scheme to another is better done via other means... such
as aliases and/or references.

Kurt