Bob If the question is "given the domain name for an organisation, I need to find its LDAP server" then I think the draft as it stands is just fine. An organisation using X.521 naming e.g. o=university of salford, c=gb, can still use the ID as it stands by creating a DC based alias entry for its organisation in its LDAP directory e.g. dc=salford, dc=ac, dc=uk and pointing this to its X.521 based organisation entry. The client can then use SRV records to find the TCP/IP address of the LDAP server and send a search request looking for david chadwick in the dc based organisation. The server will simply dereference the alias, map the dc organisation alias into the X.521 organisation and continue the search from there. Therefore I dont think the ID needs to be altered to accommodate X.521 based LDAP servers. They simply need to add an alias for their domain name into their LDAP server. David (note. if my original question is not the one that the X.521 guys are wanting to answer, then if they tell me what it is, I will see if that is answerable with a different solution) RL 'Bob' Morgan wrote: > > 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" -- ***************************************************************** David Chadwick, BSc PhD Post: IS Institute, University of Salford, Salford M5 4WT Tel: +44 161 295 5351 Fax +44 161 745 8169 Mobile: +44 790 167 0359 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Projects: http://sec.isi.salford.ac.uk Understanding X.500: http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string: MLJ9-DU5T-HV8J *****************************************************************
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