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

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
>> Cc: ned.freed@mrochek.com; Patrik Fältström; Michael Armijo; 
>> Paul Leach; Levon Esibov; rlmorgan@washington.edu; 
>> ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se
>> 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.

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

>2. By servers wishing to generate referrals to Naming Contexts for which
>it doesn't have any other way to return location information.

Should such a server publish "" as a value of namingContexts
or not?

>In addition, standards for other scenarios may require or allow its its
>use in those scenarios.



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