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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:28 PM 2002-08-15, Paul Leach wrote:
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
>> Sent: Thursday, August 15, 2002 15:09
>> To: Paul Leach
>> Subject: RE: [ldapext] draft-ietf-ldapext-locate
>> At 02:10 PM 2002-08-15, Paul Leach wrote:
>> >> -----Original Message-----
>> >> From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
>> >> Sent: Thursday, August 15, 2002 12:33
>> >> To: Kurt D. Zeilenga
>> >> Subject: Re: [ldapext] draft-ietf-ldapext-locate
>> ><snip>
>> >> >  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's a very reasonable answer.
>> >> > 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.
>> >
>> >I don't agree with this, because there are existing specs that don't 
>> >prescribe its use, where is was in fact the intent that this 
>> mechanism 
>> >be allowed to be used.
>> 
>> I have a problem with allowing use of locate whenever or 
>> whereever an implementation might choose to use it.  For 
>> example, it would be not be appropriate for a server 
>> implementing draft-zeilenga-ldap-namedref (approved for 
>> publication) to replace an empty hostpart of a LDAP URLs of a 
>> referral object based on DNS SRV information when generating 
>> referrals and search references (writing the hostpart is not 
>> allowed by namedref). However, if the object was a dnsref 
>> instead, then the server should rewrite the empty hostpart 
>> because that's exactly what the technical specification 
>> (draft-zeilenga-ldap-dnsref, presently expired) prescribes.
>
>You're jumping the gun. I'm not saying that it should be able to be used
>anywhere an implementation wants to.
>I'm saying that for the two purposes listed below , implementations may
>use it.

I'm saying that current specifications are inadequate to allow
implementations to use it without further specification.

>> >I propose that we say this about when it MAY be used:
>> >
>> >1. By clients wishing to locate an authoritative LDAP server for DNs 
>> >that contain DCs on the right side of a DN, when they have not been 
>> >configured with either implementation specific information to the 
>> >contrary, or when they are not using some other (future) 
>> standard for 
>> >locating said LDAP server.
>> 
>> I have problem with locate providing a specification of this
>> application of the mechanism.   For example, this specification
>> would state whether it was appropriate or not for a client to 
>
>I just don't understand the preceding sentence.

Sorry, I meant "I have NO problem with...".  That is, I believe locate
should provide a technical specification detailing this application
of the locate mechanism.

>> ignore explicit location information provided with a DN... or 
>> whether the client which obtained a DN from a server should 
>> ask that server for location information before using the 
>> locate mechanism.
>
>That's what I meant by "using some other future standard". If some
>standard says "thou shalt not ignore this explicit location
>information", then this item doesn't apply.

In my opinion, we need to either say "Future specifications will
prescribe where this mechanism can be used" or we need to
prescribe where this mechanism can be used in current
specifications (and allow future specifications to prescribe
additional uses of the mechanism).


>AFAIK, there is currently no other standardized way to find LDAP
>servers.

There is no standard mechanism for a client to determine its
access point into the distributed information service.  However,
once the client has knowledge of an LDAP server, there is
a standardized way for clients to find servers holding other
DNs.  (Unfornately, most servers don't have much knowledge
to share.)

When should an LDAP client use the DNS SRV locate mechanism
instead of the native LDAP mechanism?

Kurt


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