[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: draft-ietf-ldapext-locate-04.txt
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