[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: A tricky matched values problem
I would definitely choose option 2. I think that any version of option 1
overly (conf)uses the Search filter. I further believe that for an
application to use option 1 that it already has to know the answer to the
answer to part of the search filter. Further still, it will not generally
be the case that every attribute type mentioned in the search filter should
be used to contribute to the MVO control computation. For example,
consider this pseudo-filter:
(&(email=*dtasi.com) (userCertificate = [certIssuedBy VeriSign Class2 CA]))
With the MVO control in the option 1 format, there is no way to indicate
that I want all of the email addresses back, and only the userCertificate
attribute values that were issued by the VeriSign Class 2 CA. So, it
appears to me that the option 1 MVO control meets a sufficiently small
portion of application developer requirements to not be that useful.
Thus, I prefer option 2 which allows the application to cleanly separate
the two different requirements.
Bruce
At 07:39 AM 10/18/99 +0200, Harald Tveit Alvestrand wrote:
>My objection is not particularly strong, but if X.500 does 1B and your 1A
>will in some cases return a different set of values, then X.500
>compatibility is broken anyway, and we should do what makes sense, rather
>than the smallest possible incompatible motification to X.500.
>
>If a return filter is the Right Thing, then it is also the Right Thing for
>X.500, and X.500 should change.
>
> Harald
>
>
>--
>Harald Tveit Alvestrand, Maxware, Norway
>Harald.Alvestrand@maxware.no
>
>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com