Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS

From: Bruce Greenblatt <[email-masked]>
Date: Mon, 17 Jan 2000 16:36:20 -0800

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.

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.

Bruce
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Tue, 18 Jan 2000 01:14:41 -0800 (PST)

> 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.

> 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"