[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS
> -----Original Message-----
> From: RL 'Bob' Morgan [mailto:rlmorgan@cac.washington.edu]
> Sent: Tuesday, January 18, 2000 1:15 AM
> To: Bruce Greenblatt
> Cc: ietf-ldapext@netscape.com
> Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP
> Services with DNS
>
>
>
> > I don't understand (or necessarily agree with) the first two
> > paragraphs of this draft. What difference does it make to this
> > mechanism what a "native" LDAP server is? If this mechanism doesn't
> > work for non-native LDAP servers, shouldn't the draft
> explain why this
> > is the case? I'd just drop this whole notion from the draft.
>
> You're right that this method is useful independent of what
> kind of LDAP
> server is to be discovered (it is of course only defined in
> the case of
> DNs that map to DNS domain names); hence this text and the
> "Internet based
> organization" bits are not needed. Also, this paragraph:
>
> This draft defines a way that native Internet LDAP servers
> can make
> use of the DNS's knowledge base to perform the same
> function, while
> still supporting integration with the X.500 directory.
>
> is misleading since the method can be used by any process, client or
> server, that wants to determine server names from a DN.
I just read the draft again, and I agree that this section seems out of
context. The phrase "the same function" seems to be unbound to any
antecedant. As I looked back at a previous draft, a paragraph got lost. It
used to say:
"A native LDAP server can not rely upon the X.500 directory's knowledge base
to locate the appropriate server to service a request on an object in a part
of the directory tree (DIT) other than the naming context(s) it stores.
This draft defines a way that native Internet LDAP servers can make use of
the DNS's knowledge base (which it stores as "glue" records) to perform the
same function, while still supporting integration with the X.500 directory."
This still isn't great, but at least there's no danglisng reference.
All I was trying to say is that native LDAP servers have a unique problem
that they wouldn't have if LDAP servers were just front ends for the X.500
directory. In that case, a client wanting to resolve a DN could contact any
LDAP server, and if the DN weren't stored in one of that server's NCs, it
could generate a referral to a better LDAP server, which would ultimately
get to the server storing the DN.
Since native LDAP servers have no backing X.500 directory, they can't do
that. What they can do is try to use DNS instead -- by constructing a DNS
name from the "DC=" components.
I don't think this is worth holding up progress for. I can make an editorial
change befre the RFC is published, if people think its really important.
Paul