more on the locate issue

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

The suggested alternative (using all DCs) is problematic as
it requires there to be DNS SRV records to be established
for all domain components used irregardless of whether they are
used to name the context.  Consider the DNs
1)  dc=foo,dc=com,ou=hostedDomains,dc=isp,dc=com
2)  dc=com,ou=hostedDomains,dc=isp,dc=com
3)  ou=hostedDomains,dc=isp,dc=com
4)  dc=isp,dc=com

which all refer to entries within the dc=isp,dc=com
naming context held by the server ldap.isp.com.  To
locate these four entries using the suggested alternative
mapping, then three SRV RRs would have to be established
at:
  _ldap._tcp.foo.com.isp.com	[1]
  _ldap._tcp.com.isp.com	[2]
  _ldap._tcp.isp.com		[3,4]

I doubt administrators wish to maintain RRs under multiple
domain names when hosting a single naming context on a
single set of servers.

Consider also the case where a user "uid=mary,dc=example,dc=com"
is allowed at will to create entries subordinate to their entry
without significant restriction (note many servers don't support
name form restrictions).  For each of these entries created using
DC RDN, the DNS service needs to be updated otherwise the entry
cannot be located.

The obvious solution is to change the algorithm such that it
walks the DNS tree.  But this would be a bad thing.  Besides
requiring multiple DNS lookups, it would cause a huge load
upon TLD and root name services.  

In examining the PKI issue, I really don't think they want
to insert DC components into the middle of their DNs... I think
what they want is a mechanism for finding services for entries
named using traditional X.500 conventions. (Note that there are
proposals for such location services.)

I believe it best to stay with the current approach.  Adding
a further note to the last paragraph of section 1 stating that
there is work in progress to define a mechanism for discovery
of services using traditional X.500 naming, possibly with a
non-normative references to Skip's and/or my proposal in this
area, might be appropriate.

Kurt