Re: Enhancement to implement V3 Referral / Search Reference Handling (ITS#546)

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

At 12:25 PM 5/30/00 -0600, Steven Sonntag wrote:
>"Kurt D. Zeilenga" wrote:
>
>> At 12:17 PM 5/29/00 -0700, Kurt D. Zeilenga wrote:
>>
>> Also take 5.1.1.3, for non-search operations, referrals returned
>> should "must have only the protocol, host, port,
>> and trailing "/"  portion of the URL contained in the ref
>> attribute" with a grain of salt.  Actually, take all of
>> named referrals with a grain of salt.  It's an I-D and it's
>> expired.
>
>Given the above, it I think that the reencode_request should ignore the
>dn and the filter
>(it doesn't re-encode the filter yet) if the request is not a search
>request.  It should leave
>the existing base dn intact. This  is the only code that knows the
>request type as it gets it
>from the ber that it is re-encoding.

Well, one must ask what does it mean to get back a URL describing
a search for a non-search operation.

RFC 2255:
  This document describes a format for an LDAP Uniform Resource Locator.
  The format describes an LDAP search operation to perform to
  retrieve information from an LDAP directory.

Seems that URLs are being used for much, much more.... I'll have
to add that to my pile of suggested LDAPv3 "clarifications."

That aside, I would be careful not to ignore the whole URL.
In particular, extensions such as !starttls need to be honored.
(we can leave this a TODO item for now).  I would rather we
not attempt to chase non-search referrals which returns
URL parameters which make no sense in the context of the
request.

(I've asked LDAPext WG chair "what's up" with named referral
draft.  I'm hoping to get this draft revised and submitted
to the IESG as a proposed standard ASAP.)

Kurt