RL 'Bob' Morgan wrote: > But the problem draft-ietf-ldapext-locate is trying to solve is finding a > DS based on a DN, which I suspect folks in our community think is a > worthwhile problem to solve. > > - RL "Bob" Bob I question your assertion above on several counts. Firstly locate is not trying to solve the above for the general case, but only for a very limited case. Quoting from locate it states "This method takes advantage of the global deployment of the DNS, by allowing LDAP server location information for any existing DNS domain to be published by creating the records described below. " Thus locate is only solving the problem once you have a domain name or a dc based DN to map into a domain name. It does not even pretend to be solving the general problem you outlined above. This is OK, since domain names are widely known and used. Secondly, I think the problem itself is something of an oxymoron. DNs are not widely known or used. You actually use an LDAP directory to find a DN if you want one, not the other way around. People usually dont know DNs, nor do they really care what they are. Therefore if a client has in its possession a DN it must have come from somewhere. If it came from a certificate, then as you say there are alternative ways of finding the LDAP server from the contents of the certificate, rather than doing some arbitrary DN mapping based on the subject DN. If it did not come from a certificate, but some other place, then why not get the other place to pass an LDAP URL containing the DN, rather than just the DN on its own. This would solve the problem nicely. After all URLs are a much more common currency than DNs. Finally we as a group should really be trying harder to help LDAP servers hold more knowledge information about each other, then the problem above tends to disappear since a client then only needs to know about one LDAP server and this will plug it into the rest of the LDAP world. Imagine how the DNS would operate if every resolver had to find the location of the DNS server it wanted before it could make domain look ups. I therefore seriously question whether the general problem you outline above is a sensible one that we should even be attempting to solve. David
begin:vcard n:Chadwick;David tel;fax:+44 1484 532930 tel;home:+44 790 167 0359 tel;work:+44 161 295 5351 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:d.w.chadwick@salford.ac.uk x-mozilla-cpt:;-16144 fn:David Chadwick end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature