LDAP server location and DN->DNS mapping

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

draft-ietf-ldapext-locate-04.txt specifies how to use DNS SRV records to
find an LDAP DS given a DN that has DC components.  This has been mostly
uncontroversial except for some procedural things (whether to include
CLDAP, etc).  It has gone thru WG last call but not yet thru IETF last
call (still waiting on a couple of nits).  However, I'd like to raise a
fundamental question about how this scheme works, since it was recently
raised to me while discussing this doc with an IESG member, who said he
didn't like it the way it is and guaranteed to raise the issue during IETF
last call.

Section 3 of the draft defines an algorithm for mapping DNs into domain
names, for purposes of using those domain names for SRV record lookups.
This algorithm says that only DNs whose most significant components are
DC= can be mapped, that is,

   cn=John Doe,ou=accounting,dc=example,dc=net

maps to

   example.net

but

   cn=John Doe,ou=accounting,dc=example,dc=net,o=Example Corp,c=us

does not map to any domain name; therefore no use of SRV records to find
an LDAP DS is defined for such a DN.

The question on the table is:  why does the proposed mapping exclude DNs
of the second form above?  The mapping algorithm might say: march thru the
DN from most significant to least significant, gathering DC components as
you go, ignoring non-DC components; when you reach the end if you have a
non-empty DNS name use it as input to the SRV record lookup.  This amounts
to jamming server-location info somewhere in the middle of an existing
naming scheme.  This looser mapping might be attractive to folks who
already have deployed directories with non-DC names, or have applications
that rely on traditional X.521-style civil naming (X.509 PKIs being the
main case, of course), who could add DC components to some lower levels of
their naming hierarchy rather than having to change from the top.

Ultimately this raises the deep issue of what kind of interoperability is
possible and desirable between traditional and DC-style naming.  While
this is interesting and important, I really don't want to wait until it's
resolved in order to progress this document.  Given that the looser
mapping seems trivial for the client to implement, I think the burden of
proof is on those who advocate the current mapping as to why its
restrictiveness is important.  While I personally think DNs with DCs
embedded in them any old place are ugly and I wouldn't design a naming
hierarchy that way, I don't see any fundamental technical problems that
should make them illegal (ie, excluded from the SRV-based location
mechanism).  Maybe others do.

 - RL "Bob"