The problem with this method is that the resolving client must already
have knowledge about the directory containing the DN. Specificly, the
resolving client must expect that the DC tree represented by the DN
is a valid internet domain.
For examlple, a an enterprise intranet directory for example.net may
have internal DNS domains internal.example.net and external.example.net
giving the DN "cn=External Person, ou=customers, dc=external, dc=example,
dc=net" However, this gives no guarentee that _ldap._tcp.external.example.net
exists on the internet. In this case it is possible that _ldap._tcp.external.net provides access to the referenced directory structure.
So not only does this method assume that the directory is arranged by DNS domain, but it also assumes that the directory is arranged by DNS domains
that are externally exposed.
I actually believe that email, or web address is a better resolution
mechanism, because they are more likely to point to an address that
can be resolved on the internet.
James A Benedict
Advisor, IP Directory Systems Architecture
Carrier Packet Solutions
NORTEL NETWORKS
Ph: (613) 763-3909
> -----Original Message-----
> From: RL 'Bob' Morgan [mailto:rlmorgan@cac.washington.edu]
> Sent: Tuesday, January 18, 2000 4: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 think this motivational material would be better put into
> the taxonomy
> draft, which seems to me to be lacking in info about why you
> would use one
> discovery technique over another. The taxonomy draft should IMHO
> highlight the SRV-record approach, which in its limited
> domain solves the
> problem quite nicely.
>
> > Can this same mechanism be used to find an LDAP server from an email
> > address? It seems like you should be able to find the
> appropriate SRV
> > record from an email address just as easy as you can from a DN that
> > conforms to the DC naming principles.
>
> This would depend on whether the organization had chosen to
> represent the
> entities with those email addresses (whatever those entities
> are) as the
> corresponding directory entries. This is recommended in RFC
> 2377 but is
> obviously optional. A DN presumably identifies a directory
> object but an
> email address may or may not. Also, IMHO finding a dir entry
> corresponding to an email address implies a search operation
> for an entry
> with that email address as an attribute (which attribute
> might vary based
> on what it is you're trying to do); whereas a DN obviously
> identifies an
> entry directly. There may be a doc to be written about
> "finding directory
> entries based on RFC 822 email addresses" ...
>
> - RL "Bob"
>
>
>