what ldapext-locate is about

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

During the recent thread of comments on draft-ietf-ldapext-locate-01.txt
Bruce Greenblatt asked this question:

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

and I think others asked it too, more or less.  I think this question is
based on a misconception of the issue that
draft-ietf-ldapext-locate-01.txt is addressing.  Since I was confused
about this too and only came to understand it after some reflection, let
me argue the point here so we can all (I hope) be clear about it.  (I've
also submitted text to the document authors along this line.)

The first parameter of the Search operation is the baseObject, "the LDAPDN
that is the base object entry relative to which the search is to be
performed."  All other substantive LDAP operations, ie Modify, Add,
Delete, ModifyDN, and Compare also all have a DN as the first parameter,
in each case specifying the directory object on which the operation is to
be performed.  To successfully perform any of these operations, the
request must eventually be processed by a server that stores that DN (or
the subtree, in the case of Search) locally.  Finding that server, based
on the DN in the request, is precisely what this document is about, no
more, no less.  This is an *internal* directory function that has to
happen for any LDAP operation to be carried out.  Whether it is done by
the client or the server doesn't matter for this discussion.  The fact
that in practice, these days, this function is almost always null --
because servers don't know anything about other servers, and clients are
configured only to talk to particular servers for particular data and
never ask about anything else -- tends to obscure this point; but opening
up the current narrow-focus nature of LDAP directory usage is exactly what
this spec is about.

On the other hand, finding a directory entry for a person who has a
particular email address, as above, is an *application* that uses the
directory, not an internal functional component of the directory itself.  
It's the same kind of thing as finding all entries of people at UW with
the surname "Lee", or using the directory to route email, or any of the
other million directory-enabled apps that specify what the DS client
should do (construct request 'R' using DN 'D', use the value of attribute
'X' to do 'Y', etc), and what schema and data should be in the DIT to
support the app.  These sorts of things certainly need to be documented,
but in their own docs.

The observation that, when looking up info about a DNS-named thing, the
DNS name is first turned into a DC-name-based DN, then back into a DNS
name to do the SRV lookup, might lead one to believe that the DN is
superfluous and can just be skipped but clearly this isn't so.  Note that
it's the client application that does the DNS-to-DN to construct the
request, while it will likely be the server, doing chaining or referral,
that does the DN-to-DNS before doing the SRV record lookup.

Agreed?

 - RL "Bob"