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

From: Bruce Greenblatt <[email-masked]>
Date: Sat, 02 Sep 2000 14:36:58 -0700

I have a question on Mapping Algorithm in Section 3.  The second paragraph 
of this section has this sentence:

"An RDN is able to be converted if it (1) consists of a single 
AttributeTypeAndValue".

Is this restriction necessary.  If an RDN is multi-valued, why should the 
mapping break?  Shouldn't things work out OK if the RDN is something like:

"dc = foo + ou = bar"?

Thanks,

Bruce
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
See my new Book on Internet Directories: 
http://www.phptr.com/ptrbooks/ptr_0139744525.html

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Sat, 2 Sep 2000 15:03:11 -0700 (PDT)

> mapping break?  Shouldn't things work out OK if the RDN is something like:

Well, we *could* permit this, of course.  This would require deciding
whether "dc=foo + dc=bar" is OK, and how to deal with ordering (since an
RDN is a SET of AVAs, which means it's unordered, right?).  So, more work,
more potential confusion, presumably little constituency for actually
using multi-AVA RDNs, especially multi-AVA RDNs one of whose components is
DC=.  Easier to say "don't do that", IMHO.  Do you think this would
actually be useful in practice?

 - RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 02 Sep 2000 15:34:08 -0700

At 02:36 PM 9/2/00 -0700, Bruce Greenblatt wrote:
>I have a question on Mapping Algorithm in Section 3.  The second paragraph of this section has this sentence:
>
>"An RDN is able to be converted if it (1) consists of a single AttributeTypeAndValue".

This is consistent with the last paragraph of Section 2 and RFC 2247.
The locate I-D should be (and I believe is) consistent with these
statements in RFC 2247.

3. Mapping Domain Names into Distinguished Names
   This section defines a subset of the possible distinguished name
   structures for use in representing names allocated in the Internet
   Domain Name System.  It is possible to algorithmically transform any
   Internet domain name into a distinguished name, and to convert these
   distinguished names back into the original domain names.
   [...]
   Distinguished names in which there are one or more RDNs, all
   containing only the attribute type DC, can be mapped back into domain
   names. Note that this document does not define a domain name
   equivalence for any other distinguished names.

Note that these statements outline a 1-to-1 relationship between
a domain and a DN of DC-only RDNs.  I believe it important to
preserve this 1-to-1 relationship between domains and DC-based DNs.

Kurt

---

From: Bruce Greenblatt <[email-masked]>
Date: Sat, 02 Sep 2000 18:59:45 -0700

At 03:34 PM 9/2/2000 -0700, Kurt D. Zeilenga wrote:
> >I have a question on Mapping Algorithm in Section 3.  The second 
> paragraph of this section has this sentence:
> >

My understanding of this sentence is that it says a DN which has only DC 
attributes can be mapped into a host name.  It doesn't say that an RDN that 
contains a DC attribute as well as another attribute cannot be mapped into 
a domain name.

>preserve this 1-to-1 relationship between domains and DC-based DNs.

OK.  I'll go with that.  How does allowing for an RDN that has DC attribute 
as well as something else not preserve this relationship...  I think that 
the draft is just a little restrictive in this respect for no particular gain.

Bruce

---

From: Bruce Greenblatt <[email-masked]>
Date: Sat, 02 Sep 2000 18:12:38 -0700

>actually be useful in practice?

I was thinking that this might be useful in various migration and 
coexistence scenarios.  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.

---

From: Mark Wahl <[email-masked]>
Date: Sat, 02 Sep 2000 21:25:17 -0500

The ability for the mapping process to be bidirectional is important as it
allows 2247 to indicate exactly where an object that is DNS-named is 
located in the directory.  If one were to introduce the ability for the DNs
to have additional components, there is no field currently defined in DNS
for encoding the set of AVAs that would be needed to complete this mapping.
There would be local tables, which seems to violate the spirit of DNS.

> contains a DC attribute as well as another attribute cannot be mapped into 

It can't be done by RFC 2247.  Another RFC perhaps, but that other RFC would 
need to show how the other AVAs are represented in DNS.

Mark Wahl, Directory Architect, Service Provider/Infrastructure
Sun Microsystems, Inc. iPlanet Alliance

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 02 Sep 2000 20:31:24 -0700

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

---

From: Bruce Greenblatt <[email-masked]>
Date: Wed, 06 Sep 2000 00:03:47 -0700

Well, whatever.  It seems to me that the only reason for requiring this to 
be bidirectional is for the LDAP server to host a DNS server.  I can think 
of many other uses for dc-naming.  However, if dc-naming is to be 
restricted for use only for DNS host entries, I think that this draft, and 
the corresponding RFC need to explicitly say that, and to strongly warn 
implementors away from using the DC attribute for anything else.

Bruce