[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] draft-ietf-ldapext-locate

At 09:57 AM 2002-08-15, ned.freed@mrochek.com wrote:
>I'm going to take the liberty of responding directly here.
>
>> >(0) It isn't clear when this approach is supposed to be used. DNs are an
>> >integral part of *every* LDAP operation. Is it the intent that an
>> >LDAP client check every DN it sees for DC fields and if it finds them use
>> >this approach. Or is it only appropriate in specific situations?
>
>> It is intended to be a general mechanism for locating LDAP servers
>> having knowledge of directory objects associated with a DN in
>> absence of location information.  This DN may have been provided
>> to the application via LDAP or other means.  If the DN was provided
>> with location information, such as a LDAP URL with host part,
>> that information should be used.  Howeer, where the DN is provided
>> without any location information, this mechanism provides a means,
>> for a subset of DNs (those using RFC 2247 naming), for the
>> application to locate servers with knowledge of the DN.
>
>> This application may be an LDAP client or server.  OpenLDAP's server,
>> for example, can use this mechanism to generate referrals to clients
>> requesting DN which it otherwise has no knowledge of.
>
>This is precisely the sort of thing I'm afraid of. OpenLDAP does this but I
>doubt SunOne Directory Server (to pick a specific example) does. And given this
>document doesn't spell out when this is supposed to be used you cannot claim
>that the issue is Sun's failure to implement this standard.

OpenLDAP supports a particular experimental service, described
in RFC 3088, which uses this location mechanism.

What I think you asking us to clarify is when should this mechanism
be implemented/used.  My answer to this is, the mechanism should be
implemented/used as detailed in the technical specification for the application (or protocol) requiring its use.

That is, I agree that implementations should not use this mechanism
unless they implement a particular technical specification which
prescribes use of the mechanism.  This should be clarified.

>THe opposite situation is also a concern. Suppose I have an LDAP library that
>implements this unconditionally and I try to use that library in a situation
>where I don't want it to happen. (Uses of DC DNs that don't expect this to
>happen do exist, you know; the product I work on in my day job is an example of
>this.)
>
>This can be fixed in a bunch of ways. The most obvious one would be to say that
>this should be implemented in the following places and whether or not it is
>used needs to be configurable.

I don't the IETF should attempt to draw lines of what belongs in
the application-specific code versus a library implementing an API.
Requirements should be placed upon the "implementation".  It is
implementor's choice on wether to use libraries or not, which
libraries to use, etc..  But regardless of the choices made, the
resulting implementation needs to meet all implementation
requirements.

Now, in a technical specification for an LDAP API, that specification
should clearly state where the location is to be used in
implemented by providers of the API.

>> >(1) This document specifies two things: How to translate a DN to a DNS
>> >name and how to use a DNS name to locate a corresponding LDAP
>> >server.
>
>> I argue that the document specifies one process, to locate LDAP
>> servers with knowledge of a particular DN, which has two steps.
>
>> >The document seems to imply that the latter is only used when a DNS
>> >name is produced by the former. I wonder if this restriction is a
>> >good idea: Isn't the ability to use SRV records to locate more generally
>> >useful than this limited context?
>
>> I don't believe this document restricts how DNS SRV records
>> can be used.  It also doesn't restrict construction of additional
>> processes for locating LDAP servers with knowledge of a particular
>> DN.  In fact, draft-zeilenga-ldap-x500-locate suggests a process
>> for DNs using geo-political naming.
>
>> Additionally, DNS SRVs could be used to answer questions such
>> as "Are there LDAP servers associated with this domain?".
>
>This is the separate case I was thinking of.
>
>> Of course, this would be followed by, "What DN is used by
>> the owner of this domain for their objects?".  If a listed
>> server provides 100s of namingContext, which one is the right one?
>> Luckily, we have RFC 2247 which says how the owner of the
>> domain should name objects.
>
>Then you should make it clear that this document specifies a single
>process, and that it does not specify a process for locating LDAP 
>servers for a given domain.
>
>                                Ned
>
>
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org
>https://www1.ietf.org/mailman/listinfo/ldapext


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext