|
>>> Mark C Smith <mcs@netscape.com> 10/25/00 8:23:53 AM
>>>
>> >>2) Missing search constraints: The following elements of a search request are missing. derefAliases, size/timeLimit, >> typesOnly. We need some of these to be available, specifically for referrals and search continuations. >> > >> >Is there a need for the continued search to operate under different values >> >of these elements? That is, are there cases where reuse of the elements >> >in the request to be continued is not possible? >> >> Well, the search continuation case might not be as strong. I suppose size/time limits >> could be specified back to the client due to those limits being partially exhausted. > >I vote for keeping the mechanism as simple as possible. Clients can >make reasonable choices for size and time limits, because these are >typically used only to keep resource consumption down. I think it just >complicates things to allow servers to suggest limits in the referrals >or continuation references. The inclusion of all search constraints isn't only for referrals and search
continuations. It would be nice to allow a client to construct an LDAP URL and
to be able to convey various constraints.
It also is needed for future applications of the LDAP URL. Today, the
iPlanet server allows one to construct a dynamic group using an LDAP URL.
Because of today's limitations, alias dereferencing and size/time
limits cannot be specified. In the future, there may be other types of
attributes that wish to hold an LDAP URL for various reasons and it is limiting
to not allow a full search operation to be expressed.
I believe the additional constraints can be added to the end of the URL as
optional elements. This would not inherently add to the complexity of the LDAP
URLs that people are used to seeing. It simply provides more consistency.
The alternative is to define a set of LDAP URL extensions that are used to
specify the additional constraints. I'm willing to write that draft if it comes
to that.
Jim
|