> -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, August 15, 2002 15:09 > To: Paul Leach > Cc: ned.freed@mrochek.com; Patrik Fältström; Michael Armijo; > Levon Esibov; rlmorgan@washington.edu; ldapext@ietf.org; > ietf-ldap@paf.se > 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 > >> 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. 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. For other purposes and protocols (that don't yet exist), I'm agreeing with you -- the spec for those protocols should say that they MUST or MAY or SHOULD use this mechanism, as appropriate for the protocol or purpose. > > >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. Gramatically, it is in the subjunctive case, or something like that. Are you trying to say what the spec should say, or what it will say if my proposal is accepted and that you don't like? > 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. AFAIK, there is currently no other standardized way to find LDAP servers. All existing mechanisms are therefore implementation specific. So, if a caller passes in a DNS name and a DN to an LDAP API that says "do a lookup on the LDAP server with this DNS name for this DN", do you want me to declare that legal or illegal? > > >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. > > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature