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

RE: A tricky matched values problem - I vote for (2)!!

To: Bruce Greenblatt <bgreenblatt@directory-applications.com>, ietf-ldapext@netscape.com, osidirectory@az05.bull.com
Subject: RE: A tricky matched values problem - I vote for (2)!!
From: David Chadwick <d.w.chadwick@salford.ac.uk>
Date: Tue, 19 Oct 1999 14:25:38 +0100
In-reply-to: <3.0.5.32.19991018223829.0091f520@pop.walltech.com>
Organization: University of Salford
References: <8E37550684B3D211A20B0090271EC59D02C4CA65@tr-exchange-1.tr.unisys.com>
Resent-date: Tue, 19 Oct 1999 06:27:39 -0700 (PDT)
Resent-from: ietf-ldapext@netscape.com
Resent-message-id: <"1JdIhD.A.0WF.7GHD4"@glacier>
Resent-sender: ietf-ldapext-request@netscape.com

Date sent:      	Mon, 18 Oct 1999 22:38:29 -0700
To:             	"Salter, Thomas A" <Thomas.Salter@unisys.com>, d.w.chadwick@salford.ac.uk
From:           	Bruce Greenblatt <bgreenblatt@directory-applications.com>
Subject:        	RE: A tricky matched values problem - I vote for (2)!!
Copies to:      	ietf-ldapext@netscape.com, osidirectory@az05.bull.com

> At 10:05 AM 10/18/99 -0400, Salter, Thomas A wrote:
> >I'm also voting for 2 for similar reasons.
> >
> >However, instead of a "search filter", I think it should just be a "SET
> >of AVA".  Eliminating the filter should eliminate all ambiguity about
> >which filter items get evaluated.  In X.500 this should be added to
> >EntryInformationSelection.  
> >
> 
> I don't think that the SET of AVA is sufficient for attribute value
> selection.  AVAs in LDAP only allow you to specify the attribute type and
> a proposed value.  They don't let you specify the relational operator. 
> This is why I proposed the "Simple Filter" construct previously.

This makes sense. However we should call the construct something 
more meaningful such as ValueSelectionFilter or similar.

David

> 
> Bruce
> 
> > > -----Original Message-----
> > > From: Anthony Hodson [mailto:aeh@xdotd.demon.co.uk]
> > > Sent: Monday, October 18, 1999 6:10 AM
> > > To: d.w.chadwick@salford.ac.uk
> > > Cc: ietf-ldapext@netscape.com; osidirectory@az05.bull.com
> > > Subject: A tricky matched values problem - I vote for (2)!!
> > > 
> > > 
> > > Hi, David!
> > > 
> > > Good to have your analysis, which I *generally* agree with.  But ...
> > > 
> > > With 1A, consider a filter OR(A, B) where, with a particular 
> > > entry, both
> > > A and B are true; as a result of this (using 1A), assume that A would
> > > cause a value x to be returned, and that B would cause a value y to be
> > > returned.
> > > 
> > > Presumably you would return both x and y with 1A, even 
> > > though neither A
> > > nor B could be *completely* said to have contributed, since 
> > > either could
> > > be omitted without affecting the outcome.
> > > 
> > > It was consideration of this kind of issue that led to the simple and
> > > easy-to-implement rough-justice rule: if a filter item is TRUE, send
> > > the value anyway.  I don't defend it at all on philosophical grounds.
> > > 
> > > My view is that your solution 2 is *much* the better 
> > > solution because of
> > > its direct approach to solving the problem, since matched-values was
> > > always a bit kloodgy for the reasons that you suggest.  I think that
> > > it would be much better for FDAS/F.510, too.  Something has to change
> > > with existing MVO implementations, and (2) presents no technical
> > > challenges.
> > > 
> > > Best wishes
> > > 
> > > Anthony
> > > 
> > > In message <E11cz2q-00018p-00@rhenium.btinternet.com>, David Chadwick
> > > <d.w.chadwick@salford.ac.uk> writes
> > > >First let me apologise for taking so long to answer all the 
> > > emails on  this 
> > > >topic, but I have been up to the proverbials in work (I 
> > > still am, its  now 
> > > >10,30pm on Sunday evening).
> > > >
> > > >Firstly I do not believe that the Molesworth principle 
> > > should apply for  the 
> > > >matched values control. This is because the user, in 
> > > specifying  this control, 
> > > >is obviously trying to limit the size of the response,  
> > > therefore the correct 
> > > >action by the server would be the Molesless  principle if 
> > > there were one i.e. if 
> > > >in doubt return less attribute values  rather than more.
> > > >But I am not advocating either principle, but rather I am 
> > > agreeing  with Paul 
> > > >Dale that sound logic and a consistent and easily  reasoned 
> > > scheme is needed. 
> > > >And as Erik said "we need to be  precise".
> > > >
> > > >Harald has rightly pointed out that quote "it might be 
> > > better to have a  control 
> > > >that tells the server something about what the client wants 
> > >  back rather than 
> > > >something about how he wants the search criteria  treated." 
> > > What matched values 
> > > >was trying to do was both with one  simple boolean. ie. the 
> > > matched values 
> > > >boolean was saying  something about what the client wanted 
> > > back (i.e. limit the 
> > > >values),  but using the search filter to specify precisely 
> > > which values are to  
> > > >be limited in the return. The trouble as we can see arose 
> > > because  the search 
> > > >filter can be a mixture of truths, unknowns and falses,  
> > > and a simple 
> > > >matchedValuesOnly boolean was too blunt a tool (as  
> > > currently specified) to 
> > > >differentiate between them. It therefore was  not precise 
> > > enough in its 
> > > >specification.
> > > >
> > > >Therefore it seems that there are two sensible options that 
> > > can be  taken:
> > > >
> > > >1) is to tighten up considerably on the definition of the 
> > > current  MVO boolean. 
> > > >There are three views of how to tighten up the  definition. 
> > > 1A) One is to say 
> > > >that only those attributes that  contributed to the overall 
> > > truth of the filter 
> > > >are governed by the MVO  boolean. 1B) Another is to say 
> > > that if the filter item  
> > > >was true then  MVO applies to the attributes in the filter 
> > > item (even if the 
> > > >subfilter  containing the filter item was false). 1C) And 
> > > the final one 
> > > >suggested  by Bruce was if the attribute was in the filter, 
> > > even if the filter 
> > > >item  was false, then apply MVO.
> > > >
> > > >2) the other is to replace the boolean by a return filter 
> > > (as  suggested by both 
> > > >Harald and Bruce) that acts on the attributes to  be 
> > > returned and filters out 
> > > >some of the values. This works  independently of, and 
> > > after, the Search filter.
> > > >
> > > >My preferred approach is the first, 1A) i.e.only those 
> > > attributes that  
> > > >contributed to the overall truth of the filter are governed 
> > > by the MVO  boolean. 
> > > >My reasons are as follows:
> > > >
> > > >I reject the current X.500 text (option 1B) for the 
> > > following reason:
> > > >subfilters that evaluate false or undefined might as well 
> > > be missing  from the 
> > > >filter, and if they were there on their own then no entries 
> > >  would be returned. 
> > > >THerefore they have no claim to act on the  returned values 
> > > of any entries.
> > > >
> > > >I reject option 1C) as it is too loose and it does not work 
> > > properly for  false 
> > > >filter items, as presumably no attribute values would be  
> > > returned from these 
> > > >attributes.
> > > >
> > > >Option 2) has its merits, and is clean. The reason for 
> > > rejecting it is  
> > > >compatibility with X.500, and that option 1A can (as Mark 
> > > points out)  do the 
> > > >same task anyway, but perhaps not quite as efficiently. So  
> > > option 2) might be 
> > > >more efficient than 1A) but at the expense of  
> > > compatibility with existing 
> > > >implementations.
> > > >
> > > >I am happy to update the ID was the proposed solution 1A 
> > > unless  anyone has 
> > > >strong objections to this.> > > > David

> > > >
> > > > ***************************************************
> > > >David Chadwick IS Institute, University of Salford, Salford 
> > > M5 4WT Tel +44 161 
> > > >295 5351  Fax +44 161 745 8169 Mobile +44 790 167 0359 Email 
> > > >D.W.Chadwick@salford.ac.uk Home Page  
> >http://www.salford.ac.uk/its024/chadwick.h
> >>tm Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> >>X.500/LDAP
> >
> >>Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key
> >validation 
> >>string MLJ9-DU5T-HV8J
> >>***************************************************
> >
> >Anthony Hodson <aeh@xdotd.demon.co.uk>      X   X    DDD
> >XdotD Associates                             X X  O  D  D
> >Spring Lanes House, Holly Spring Lane         X  OOO D   D  
> >Bracknell, Berks RG12 2JL, ENGLAND           X X  O  D  D
> >Tel: +44 1344 310665                        X   X    DDD
> >Mob: +44 771 360 7086
> >Fax: +44 870 056 8242
> >
> >
> >
> ==============================================
> Bruce Greenblatt, Ph. D.
> Directory Tools and Application Services, Inc.
> http://www.directory-applications.com
> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

References:
- RE: A tricky matched values problem - I vote for (2)!!
  - From: "Salter, Thomas A" <Thomas.Salter@unisys.com>
- RE: A tricky matched values problem - I vote for (2)!!
  - From: Bruce Greenblatt <bgreenblatt@directory-applications.com>

Prev by Date: Re: Comments on aci-model-04
Next by Date: Re: vendorACI attribute in draft-ietf-ldapext-acl-model-04.txt
Index(es):
- Chronological
- Thread